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ABSTRACT 

T.^.is tnesis presents an irr-piemer ration of process 
.nana^ement for a security Kernel based sf^cure arcnival 
storage system (?ASS). Tne implernentioc is based cn a family 
of secure. distributed, frulti-microprocessor operating 
systems designed to provide multilevel internal security and 
contrcllea snaring of data an-ong autncrized users. Process 
scneduling is effected by one naif of a two level Traffic 
Controller tnat binds processes to virtualized processors. 
Inter-process communication mecnanisms for syncnronization , 
mutual exclusion, and message passing among processes are 
provided by utilization of event''cunt and sequencer 
primitives. Tne implementation structure is based upon 
levels Of abstraction and is loop free to permit future 
expansion to more complex members of tne design family. 
Implementation was completed on tne ADVANCED .'ilCRC COy.PUTR'S 
sm 96/^116 AmZ80iJ2 16 rit yonoioard Computer. 
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I. INTRODUCTION 


This thesis addresses the impleri’entation of process 
management functions for the Secure Archival Storage System 
or SASS. This system is designed to provide multilevel 
secure access to information stored for a network of 
possibly dissimilar host computer systems and the controlled 
sharing of data amongst authorized users of the SASS. 
Effective process management is essential to insure 
efficient use and control of the system. 

Among the major accomplishments of the wort reported 
here are the inclusion of provisions for efficient process 
creation and management. These functions are provided 
through the establishment of a system Traffic Controller and 
the creation of a virtual interrupt structure. An effective 
mechanism for inter-process communication and 
synchronization is realized through an Event Manager that 
maies use of uniquely identified segments supported •►y 
eventcount and sequencer primitives. A hardware controlled 
two domain operational environment is created with the 

I 

necessary interfacing between domains provided by a software 
”gate” mechanism. Additional support is provided through 
considerable wora in the area of database initialization and 
a technique for limited dynamic memory allocation. 
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This implementation was completed on the commercial AMC 
Am96/4116 MonoBoard Computer with a standard Multibus 
interface. 


A. BACKGROUND 

The brief history of digital computers has been 
characterized by rapid advances in hardware technology and a 
continual increase in the number and variety of its 
applications. The advent of the microprocessor has enabled 
virtually every level of our society to mate use of computer 
resources. Today's "des4 top" microcomputers, costing less 
than a thousand dollars, have more computing power than the 
"giant" computers of the early I950's that cost hundreds of 
times that amount. 

These rapid advances in computer hardware technology 
have reversed the economics of the computer design 
environment. While hardware costs have decreased, the 
relative costs of the software required to effectively 
utilize this hardware has steadily increased until it now 
dominates the overall cost of a computer system. This 
economic reversal requires that developed software be 
logical, easy to read, relatively maintenance free, and easy 
to debug. Unfortunately, microcomputer operating systems and 
applications software tend to be highly specialized, thus 
failing to reasonably exploit the potential of tne 
microprocessor. 
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As tne usaffe of computers has expanded, expeclaily in 
the area of sensitive information handling, the need for 
information security has received treater recognition. While 
ad-hoc attempts have been made to provide internal computer 
security on larger systems, the problem of information 
security on microprocessors has been largely ignored to 
date. 

In an attempt to address the above problems, O'Connell 
and Richardson [1] outlined a hiffh level design for a 
microprocessor based secure operating system. The goal of 
this design was to provide information security, distributed 
processing, multiple protection domains, configuration 
Independence, multiprocessing, and multiprogramming. Since 
all computer applications do not require such a broad and 
general operating system, the design provided for a family 
of operating systems. This allows a member of the family to 
incorporate only the subset of family functions needed for 
its specific application, while providing for future 
expansion. The SASS is a member of this operating system 
family^ 

A brief history of prior worlc done on the SASS is now 
provided. Parirs [Hj provided the design for the SASS 
Supervisor. Tne actual implementation of the Supervisor 
design has not been addressed to date. The initial design of 
tne SASS Security Kernel was completed by Coleman [3J . The 
works of O'Connell and Richardson [Ij, Parks [2J , and 
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Coleman [3] are available as a single publication from NTIS 
and DDC in a report prepared by Schell and Cox [21] . Further 


refinements of tne Kernel design and partial Kernel 
implementation has been accomplished in three additional 
thesis efforts. Moore and Gary [4j provided the detailed 
design and partial implementation of the Memory Manager 
module. Design refinements for the Inner Traffic Controller 
and Traffic Controller modules as well as Implementation of 
the Inner Traffic Controller was provided by Reitz [5]. 
Wells [6j provided implementation of the Segment Manager and 
Non-Discretionary Security modules as well as partial 
Implementation of distributed Memory Manager functions. 
These design and implementation efforts provided the basis 
for the work described here. 


E. EASIC CONCEPTS/DEFINITIONS 

This section provides an overview of several concepts 
essential to the SASS design. Readers familiar with SASS or 
with secure operating system principles may wish to skip to 
the next section. 

1. Process 

The notion of a process nas been viewed in many ways 
in computer science literature. Or^anicK [7] defines a 
process as a set of related procedures and data undergoing 
execution and manipulation, respectively, by one of possibly 
several processors of a computer. Madnick and Donovan [Bj 
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view a process as the locus of points of a processor 
executing a collection of programs. Reed [9j describes a 
process as the sequence of actions taJten by some processor. 
In other words, it is tne past, present, and future 
"history” of the states of the processor. In the SASS 
design, a process is viewed as a logical entity entirely 
characterized by an address space and an execution point. A 
process' address space consists of the set of all memory 
locations accessible by the process during its execution. 
This may be viewed as a set of procedures and data related 
to the process. The execution point is defined by the state 
of the processor at any ^iven instant of process execution. 

As a logical entity, a process may have logical 
attributes associated with it, such as a security access 
class, a unique identifier, and an execution state. This 
notion of logical attributes should not be confused with the 
more typical notion of physical attributes, such as location 


in memory, page s 

ize, etc. In 

SASS , a 

process 

is given 

a 

security access 

class, at 

the time 

of i ts 

creation, 

to 

specify what au 

thorizatlon 

it possesses in 

terms 

of 

information acces 

s (to be discussed in 

the next 

section). 

It 


is also given a unique identifier that provides for its 
Identification by the system and is utilized for interaction 
atronff processes. A process may exist in one of three 
execution states: 1) running, 2) ready, and 3) bloclced. In 
order to execute, a process must be mapped onto (bound to) a 
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pnysical processor in tne system. Sucn a process is said to 
tte in the "running" state. A process that is not mapped onto 
a pnysical processor, but is otnerwise ready to execute, is 
In the "ready" state. A process in tne "’blocked" state is 
waiting for some event to occur in tne system and cannot 
continue execution until the event occurs. At that time, the 
process is placed into tne ready state. 

2. Information Security 

There is an ever increasing demand for computer 
systems that can provide controlled access to the data it 
stores. In this thesis, "information security" is defined as 
tne process of controlling access to information based upon 
proper authorization. The critical need for information 
security should be clear. Banks and other commercial 
enterprises risk the theft or loss of funds. Insurance and 
credit companies are bound by law to protect the private or 
otnerwise personal information they maintain on their 
customers. Universities and scientific institutions must 
prevent the unauthorized use of their often over-burdened 
systems. The Department of Defense and other government 
agencies must face the very real possibility that classified 
information is being compromised or that weapon systems are 
being tampered with. In fact, security related problems can 
be found at virtually every level of computer usage. 

In tne past, attempts nave been made to identify tne 
security weakness of computer systems by trial and error and 
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then fix them. However, Schell [li?] has shown that security 
cannot he "added on" to an existing system with any degree 
of confidence that the resulting security system is 
impregnable. Security must he explicitly designed into a 
system from first principles. The icey to achieving provable 
information security is realized in the concept of the 
"security kernel." Schell [llj provides a detailed 
discussion of the use of this concept in the methodical 
design of system security. 

The security of computer systems processing 
sensitive Information can be achieved by two means: external 
security controls and Internal security controls. In the 
first case, security is achieved by encapsulating the 
computer and all its trusted users within a single security 
perimeter established by physical means (e.g., armed guards, 
fences, etc.) This means of security is often undesirable 
due to its added cost of implementation, tne inherent risk 
of error-prone manual procedures, and the problem of 
trustworthy but error-prone users. Also, since all security 
controls are external to the computer system, the computer 
is incapable of securely handling data at differing security 
levels or users with differing degrees of authorization. 
This restriction greatly limits the utility of modern 
computers. Internal security controls rely upon the computer 
system to internally distinguish between multiple levels of 
Information classification and user authorization. This is 
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clearly a irore desirable and flexible approach to 
information security. This does not mean, nowever, tnat 
external security is not needed. The optimal approach would 
be to utilize internal security controls to maintain 
information security and external security controls to 
provide physical protection of our system against sabotage, 

theft, or destruction. The primary concern of this thesis is 

✓ 

information security and will therefore center its 
discussion on the achievement of information security 
through implementation of the security kernel concept. 

One might argue that a "totally secure" computer 
system is one that allows no access to its classified or 
otherwise sensitive information. Sucn a system would not be 
of much value to its users. Therefore, when we say that a 
system provides information security, it is only secure with 
respect to some specific external security policy 
established by laws, directives, or regulations. There are 
two distinct aspects of security policy; non-discretionary 
and discretionary. Each user (subject^ of the system is 
given a label denoting wiiat classification or level of 
access the user is authorized. Likewise, all information or 
segments (objects) within the system are labelled with their 
classification or level of sensitivity. The 
non-discretionary security mechanism is responsible for 
comparing the authorization of a subject with the 
classification of an object and determining what access, if 
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any, should he granted. The DOD security classification 
system provides an example of the non-discretionary security 
policy and is the policy implemented in SASS. Tne 
discretionary security policy is a refinement of the 
non-discretionary policy. As sucn, it adds a higher degree 
of restriction by ailowinc a subject to specify or restrict 
who may have access to his files. It must be emphasized that 
the discretionary policy is contained within the 
non-discretionary policy and in no way undermines or 
substitutes for it. This prevents a subject from granting 
access that would violate the non-discretionary policy. An 
example of discretionary security is provided by the DOD 
"need to know" policy. In SASS, the discretionary policy is 
implemented within the supervisor [2j by means of an Access 
Control List (ACL). There is an ACL maintained for every 
file in tne system, wnich provides a list of all users 
authorized access to that file. Every attempt by a user to 
access a file is first cnecked against tne ACL and then 
checked against the non-discretionary security policy. The 
"least" or "most restrictive" access found in these checks 
is then granted to the user. 

The relationship between the labels associated with 
the subject's access class (sac) and the object's access 
class (oac) is defined by a lattice model of secure 


information flow [12J as follows ("1" denotes "no 
relationship"): 
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sac 


oact 


1. sac = oaCf read and write access permitted 

2. sac > oac, read access permitted 

3. sac < oac, write access permitted 

4. sac I oac, no access permitted 

In order to understand how these access levels are 
determined, it is necessary to sain an awareness of and 

consideration for several basic security properties. 

The "Simple Security Property" deals with "read” 
access. It states that a subject may nave read access only 
to those object's whose classification is less than or equal 
to the classification of the subject. This prevents a 
subject from reading any object possessing a classification 
higher than his own. 

The "Confinement Property” (also known as 
"^-property”) governs "write” access. It states tnat a user 
may be granted write access only to those objects whose 
classification is treater than or equal to the 

classification of the subject. This prevents a user from 
writing information of a higher classification (e.e.. 
Secret) into a file of a lower classification (e.g.. 
Unclassified). It is noted that while this property allows a 
user to write into a file possessing a classification higher 
than his own, it does not allow him access to any of the 
data in that file. The SASS design does not allow a user to 
"write u^” to higher classified files. Therefore, in SASS, 
"sac < oac” denotes "no access permitted.” 
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The "Compatibility Property deals with the creation 
of objects in a hierarchical structure. In SASS, objects 
(segments) are hierarcnicaily organi 2 ed in a tree structure. 
This structure consists of nodes witn a root node from which 
the tree eminates. The Compatibility Property states that 
the classification of objects must be non-decreasing as we 
move down the hierarchical structure. This prevents a parent 
node from creatine a child node of a lower classification. 

Several prerequisites must be met in order to insure 
that the security feernel desien provides a secure 
environment. Firstly, every attempt to access data must 
invoke the Kernel. In addition, the Kernel must be Isolated 
and tamperproof. Finally, the Kernel design must be 
verifiable. This implies that the mathematical model, upon 
which the Kernel is based, must be proved secure and that 
the Kernel is shown is to correctly implement this model. 

3. Segmentation 

Segmentation is a key element of a security Kernel 
based system. A segment can be defined as a logical grouping 
of information, such as a procedure, file or data area [8J. 
Thereforet we can redefine a process' address space as the 
collection of all segments addressable by that process. 
Segmentation is the technique applied to effect management 
of those segments within an address space. In a segmented 
environment, all references within an address space require 
two components: 1) a segment specifier (cumber) and 2) the 
location (offset) within the segment. 
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A se^rment may nave several logical and pnysical 
attributes associated witn it. Tde logical attributes may 
include the segment's classification, size, or permissable 
access (read, write, or execute). These logical attributes 
allow a segment to nicely fit the definition of an object 
within the security kernel concept, and thus provide a means 
for the enforcement of information security. A segment's 
physical attributes include the current location of the 
segment, whether or not the segment resides in main memory 
or secondary storage, and where tne segment's attributes are 
maintained by a segment descriptor. The segment descriptors 
for each segment in a process' address space are contained 
within a Descriptor Segment (viz., the MMU Image in SASS) to 
facilitate the memory management of that address space. 

Segmentation supports information sharing by 
allowing a single segment to exist in tne address spaces of 
multiple processes. This allows us to forego the maintenance 
of multiple copies of tne same segment and eliminates tne 
possibility of conflicting data. Controlled access to a 
segment is also enforced, since each process can nave 
different attributes (read/write) specified in its segment 
descriptor. In the implementation of SASS, any segment which 
is shared, but has "read only" access by every process 
sharing it, is placed in the processor local memory 
supporting each of these processes rather than in the global 
memory. This Implies the maintenance of multiple copies of 
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some snared segments. It is noted tnat tne problem of 
"conflicting data” is avoided since tnis only applies to 
read only segments. Tnis apparent waste of memory and nonuse 

of existing snaring facilities is justified dy a design 
decision to provide maximum reduction of bus contention 
among processors accessing global memory. This reduction in 
bus contention is considered to be of more importance tnan 
the saving of memory space provided by single copy sharing 
of read only segments. This decision is also well supported 
by the occurrence of decreasing memory costSt which we have 
experienced in terms of high speed bus costs. 

4. Protection Domains 

The requirement for isolating the Kernel from the 
remainder of the system is achieved by dividing the address 
space of each process into a set of hierarchical domains or 
protection rings [13J. O'Connell and Richardson [Ij defined 
three domains in the family of secure operating systems: the 
user, the supervisor, and the Kernel. Only two domains are 
actually necessary in the SASS design since it does not 
provide extended user applications. The Kernel resides in 
the inner or most privileged domain and has access to ail 
segments in an address space. System wide data bases are 
also maintained within the Kernel domain to insure their 
accessibility is only through the Kernel. Tne Supervisor 
exists in the outer or least privileged domain where its 
access to data or segments within an address space is 
restricted. 
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While protection domains may Pe created through 
either hardware or software mechanisms, a hardware 
implementation provides much greater efficiency. Current 
microprocessor technology only provides for the 
implementation of two domains. This two domain restriction 
does not support O'Connell and Richardson's complete family 
design, hut it is sufficient to allow hardware 
implementation of the ring structure required by the SASS 
subset. 


5. AlLS.mfi.tl Qfl 

Dijfcstra [14] has shown that tne notion of 
abstraction can be used to reduce the complexity of a 
problem by applying a general solution to a number of 
specific cases. A structure of increasing levels of 
abstraction provides a powerful tool for tne design of 
complex systems and generally leads to a better design with 
greater clarity and fewer errors. 

Eactt level of abstraction creates n virtual 
hierarchical machine [8] which provides a set of "extended 
instructions” to the system. A virtual machine cannot maice 
calls to another virtual machine at a higher level of 
abstraction and in fact is unaware of its existence. This 
implies that a level of abstraction is independent of any 
higher levels. This independence provides for a loop-free 
design. Additionally, a higher level may only ma^e use of 
the resources of a lower level by applying the extended 
instruction set of the lower level virtual machine. 
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Therefore, once a level of aostractlon is created, any 
nigner level is only interested in the extended instruction 
set it provides and is not concerned with the details of its 
implementation. In SASS, once a level of abstraction is 
created for the physical resources of the system, these 
resources become "virtualized" making the higher levels of 
the design independent of the physical configuration of the 
system. 


C. THESIS STRUCTURE 

This thesis describes the implementation of the process 
management functions for the SASS. The design base for this 
implementation evolved from the secure family of operating 
systems designed by O'Connell and Richardson [Ij . The 
programming language utilized in this implementation was 
PLZ/ASM assembly code [20J . 

Chapter I provided an introduction to the Secure 
Archival Storage System and a discussion of the basic 
concepts which underlie a secure operating system 
environment. 

Chapter II will provide a discussion of tne SASS design. 
An overview of the entire SASS system is presented along 
with more detailed description of the modules comprising 
SASS and their associated databases. 

Chapter III discusses the issues bearing on this 
Implementation and the refinements made to previous SASS 
related worK. A discussion concerning the initialization of 


24 























































tne databases utilized by tne current SASS demonstration is 
also presented. 

Chapter IV presents the implementation of process 
management (viz., tne Traffic Controller, Event Manager, 
Distributed Memory Manager, and Gate Keeper stub modules). A 
description of design and implementation criteria, and 
decisions made during implementation are also discussed in 
this chapter. 

Chapter V provides the conclusions reached, the status 
of the research, and recommendations relative to the 
continuation and extension of this worir. 

The appendices include the PLZ/ASM code for tne modules 
implemented and refined. The complete program listings for 
the Secure Archival Storage System may be obtained from a 
report prepared by Schell and Cox L22]. 
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II. SECURE ARCHIVAL STORAGE SYSTEM DESIGN 


This chapter provides an overview of the SASS in its 
current design state. The intent of this summary is 
threefold. First, it is intended to provide an overall 
understanding of the SASS itself. Secondly, it will provide 
an interrelationship between the work done in this thesis 
and previous wortc performed on SASS. Lastly, it provides a 
current base upon which further SASS development can occur. 


A. BASIC SASS OVERVIEW 


The purpose of the Secure Archi 
provide a secure ’’data warehouse" or 
can be accessed and shared by 
computer systems possessing 
classifications. The primary goals o 
provide information security and co 
among system users. 

Figure 1 provides an example of 
The system is used exclusively 
storage system and does not provide 
to its users. Thus the users of the 
store, retrieve, or modify files w 
computers are hardwired to the syste 
the Z8001 with each connection 


val Storage System 
information pool 
a variable set o 
differing se 
f the SASS design 
ntrolled sharing o 


is to 
which 
f host 
curity 
are to 
f data 


a possible SASS usage, 
for managing an archival 
any programming services 
SASS may only create, 
Ithin the SASS. The host 
m via the I/O ports of 
having a fixed security 
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classification. Eacfi host must have a separate connection 
for each security level it wishes to worfi: on (It is 
important to note that Figure 1 only represents the logical 
interfacing of tne system. Specifically, the actual 
connection with the host system must he interfaced with the 

Kernel as the I/O instructions for tne port are privileged). 

/ 

In our example. Host #1 can create and modify only Top 
Secret files, hut it can read files which are Top Secret, 
Secret, Confidential, or Unclassified. Llirewise, Host #2 can 
create or modify secret files, using its secret connection 
or confidential files, using its confidential connection. 
Host #2 cannot create or modify Top Secret or Unclassified 
files. 

In order to provide information security and controlled 
sharing of files, the SASS operates in two domains: (l) the 
Supervisor domain and (2) tne Kernel domain. The SASS 
achieves this desired environment through a distributed 
operating, system design which consists of two primary 
modules: the Supervisor and the Security Kernel. Each host 
system connected to the SASS nas associated with it two 
processes within the SASS which perform the data transfer 
and file management on benalf of that host. Tne host 
computer communicates directly with its own I/O process and 
File Manager process within tne SASS. 

We can use our notion of abstraction to present a system 
overview of the SASS. The SASS consists of four primary 
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levels of abstraction: 

Level 3-The Host Computer Systems 
Level E-Tbe Supervisor 
Level 1-Ttie Security Kernel 
Level 0“The SASS Hardware 

A pictorial representation of tdis abstract system overview 
is presented in Figure 2. This representation is limited to 
a dual nost system for clarity and space restrictions. Note 
that the Gate Keeper module is in actuality the logical 
boundary between levels one and two and as such will be 
described separately. 

Level 3» the host computer systems, of SASS has already 
been addressed. It should be noted that the SASS design 
maJces no assumptions about the host computer systems. 
Therefore each host may be of a different type or size 
(i.e.- micro, mini, or maxi-computer system). Furthermore,* 
the necessary physical security of tne host systems and 
their respective data linAs with the SASS is assumed. 


B. SUPERVISOR 

Level 2 of the SASS system is composed of the Supervisor 
domain. As already stated, the SASS consists of two domains. 
The actual implementation of these domains was e-reatly 
simplified since the ZSOOl microprocessor provides two modes 
of execution. The system mode, with which the Kernel was 
implemented, provides access to all machine instructions and 
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Figure 2. System Overview (Dual Host) 
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all segments within the system. The normal mode, with 
the Supervisor was implemented, only provides access to a 
limited subset of machine instructions and segments within 
the system. Therefore, tne Supervisor operates in an outer 
or less privileged domain than the Kernel. 

The purpose of the Supervisor is to manage tne data link 
between the host computer systems and the SASS by means of 
Input/Output control, and to create and manage tne file 
hierarchy of each host within the SASS. These functions are 
accomplished via an Input/Output (I/O) process and a File 
Manager (FM) process within the Supervisor. A separate FM 
and I/O process are created and dedicated to each host at 
the time of system initialization. 

1. File Manager Process 

The FM process directs the interaction between the 
host computer systems and the SASS. It interprets all 
commands received from the Host computer and performs the 
necessary action upon them through appropriate calls to the 
Kernel. The primary functions of the FM process are tne 
management of the Host's virtual file system and the 
enforcement of the discretionary security policy. 

The virtual file system of the Host is viewed as a 
hierarchy of files which are implemented in a tree 
structure. The five basic actions which may be initiated 
upon a file at this level are: 1) to create a file, 2) to 
delete a file, 3) to read a file, 4) to store a file, and 5) 
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to modify a file. The I'M process utilizes a IM Known Segment 
Table (I'M_KST) as tne primary database to aid in tnis 
management. 

Tde FM process maintains an Access Control List 
(ACL) through which it enforces tne discretionary security 
in SASS. The FM process initializes an ACL for every file in 
its Host's file system. The ACL is merely a list of all 
users that are authorized to access mat file. Tne ACL is 
checfeed upon every attempt to access a file to determine its 
authorization. The user (nost computer) directs tne FM 
process as to what entries or deletions should be made in 
tne ACL, and as such, specifies wno ne wisnes to nave access 
to his file. As noted earlier, discretionary security is a 
refinement to the Non-Discretionary Security Policy and 
therefore can only be utilized to add further access 
restrictions to those provided by the Non-Discretionary 
Security.' This prevents a user from granting access to a 
file to someone who otherwise would not be authorized 
access. 

2. Input/Output Process 

The I/O process is responsible for managing the 
input and output of all data between tne nost computer 
systems and the SASS. The I/O process is subservient to the 
FM process and receives all of its commands from it. Data is 
transferred between the SASS and Host Computer systems in 
fixed size "pacicets". These paclcets are brolcen up into three 


32 









basic types: 1) a synchronization packet, 2) a comnand 
packet, and 3) a data packet. In order to insure reliable 
transmission and receipt of packets between the Eost 
computer and the SASS, there must exist a protocol between 
them. Parks [2] provides a more detailed description of 
these packets, and a possible multi-packet protocol. 

C. GATE KEEPER 

The primary objective of the gate keeper is to isolate 
the Kernel and make it tamperproof. This goal is 
accomplished by reason of a software ring crossing mecnanism 
provided by the ^ate keeper. In terms of SASS, this notion 
of ’’ring-crossing" is merely the transition from tne 
Supervisor domain to the Kernel domain. As noted earlier, 
the gate keeper establishes the logical boundary between the 
Supervisor and the Kernel, and as a matter of course, it 
provides a single software entry point (enforcea by 
hardware) into the Kernel. Therefore, any call to the Kernel 
must first pass through the gate keeper. 

The ffate keeper acts as a trap handler. Once it is 
invoked by a user (Supervisor) process, the hardware preempt 
interrupts are masked, and the user process' registers and 
stack pointer are saved (within the kernel domain). It then 
takes the arsuirent list provided by the caller and validates 
these passed parameters to insure tneir correctness. To aid 
in the validation of these parameters, the «ate keeper 
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utilizes tne Parameter Table as a database. Tne Parameter 
table contains all of tne permitted functions provided by 
the Kernel. These relate directly to the extended 
instruction set (viz.. Supervisor calls) provided by the 
Kernel (these extended instructions will be described in the 
next section). If an invalid call is encountered by the gate 
iteeper, an error code is returned, and the Kernel is not 
invoiced. If a valid call is encountered by the gate Keeper, 
the arguments and control are passed to the appropriate 
Kernel module. 

Once the Kernel has completed its action on tne user 
request, it passes the necessary parameters and control bacK 
to the gate Keeper. At this point, the gate Keeper 
determines if any software virtual preempt interrupts have 
occurred. If they have, then the virtual preempt handler is 
invoKed vice the Kernel being exited (virtual interrupt 
structure is discussed in chapter III). Correspondingly, if 
a software virtual preempt has not occurred, then the return 
arguments are passed to the user process. The user process' 
registers and stacK pointer (viz., its execution point) are 
restored and control returned to the Supervisor domain. A 
detailed description of the Gate Keeper interface and 
implementation is provided in chapter IV. 
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D. DISTRIBUTED KERNEL 

Level 1 of our abstract view of SASS consists of two 
components: the distributed Kernel and tne non-distributed 
Kernel. These two elements comprise tne Security Kernel of 
the SASS. The Security Kernel has two primary objectives: 1) 
the management of the system's hardware resources, and 2) 
the enforcement of the non-discretionary security policy. It 
executes in the most privileged domain (viz., the system 
mode of the Z8001) and has access to all machine 
instructions. The following section will provide a brief 
description of the distributed Kernel, its components, and 
the extended instruction set it provides. A discussion of 
the non-distributed Kernel will be giver in the next 
section. 

The distributed Kernel consists of those Kernel modules 
whose segments are contained (distributed) in the address 
space of every user (Supervisor) process. Thus, in effect, 
the distributed Kernel is shared by all user processes in 
the SASS. The distributed Kernel is composed of the Segment 
Manager, the Event Manager, the Non-Discretionary Security 
Module, tne Traffic Controller, tne Inner Traffic 
Controller, and the Distributed Memory Manager Module. The 
Segment Manager and the Event Manager are the only "user 
visible" modules in the distributed Kernel. In other words, 
the set of extended instructions available to user processes 
invofce either the Segment Manager or the Event Manager. 
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1. Segment Manager 

The objective of the Segment Manager is the 
management of a process' segmented virtual storage. The 
Segment Manager is invoiced by calls from the Supervisor 
domain via the gate iceeper. Calls to tne Segment Manager are 
made by means of six extended instructions provided by the 
segment manager. These extended instructions (viz., entry 
points) are: l) CRBAT]!)_SEGMENT, 2 ) DELETE_SEGMENT, 3) 
MAKB_KNOWN, 4) TERMINATE, 5) SM_SWAP_IN, and 6) SM_SWAP_OUT. 
The extended instructions CREATE_SEGMENT and DELETE_SEGMENT 
add and remove segments from the SASS. MAKE_KNOWN and 
TERMINATE add and remove segments from the address space of 
a process. Finally, SM_SWAP_IN and SM_SWAP_OUT move segments 
from secondary storage to main storage and vice versa. 

The primary database utilized by the Segment Manager 
is the Known Segment Table (KST) . A representation of the 
structure of the KST is provided in figure 3. The KST is a 
process local database that contains an entry for every 
segment in the address space of that process. The KST is 
indexed by segment number with each record of the KST 
containing descriptive information for a particular segment. 
The KST provides a mapping mechanism by which the segment 
number of a particular segment can be converted into a 
unique handle for use by the Memory Manager. The Memory 
Manager will be discussed in the next section. 
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Known Segment Table (KST) 
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2. Event t*^anager 


The purpose of the Event Manager is the managerrent 
Of event data which is associated with interprocess 


communications 

within 

tne SASS. 

This 

even t 

data 

is 

imjJlemented by 

means 

of eventcounts 

(a synchronization 

primitive discussed by 

Reed [15J). 

Tne 

Event 

Manager 

is 


invoked, via the Gate Keeper, by user processes residing in 
the Supervisor domain. There are two eventcounts associated 
with every segment existing in the Supervisor domain. These 
eventcounts (viz., Instance l and Instance 2) are maintained 
in a database residing in the Memory Manager. The Event 
Manager provides its management functions through its 
extended instruction set READ, TICKET, ADVANCE, and AWAIT, 
and in conjunction with the extended instructions TC_ADVANCE 
and TC_AWAIT provided by the Traffic Controller (to be 
discussed next). These extended instructions are based on 
the mechanism of eventcounts and sequencers [15J. The Event 
Manager verifies the access permission of every interprocess 
communication request through the Non-Discretionary Security 
Module. The extended instruction READ provides tne current 
value of the eventcount requested by the caller. TICKET 
provides a complete time ordering of possibly concurrent 
events through the mechanism of sequencers. The Event 
Manager will be discussed in more detail in chapter IV. 

3. Non-Discretionary Security Module 

The purpose of the Non-Discretionary Security Module 
(NDS) is the enforcement of the non-discretionary security 
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policy of tne SASS. Wnile tne current implementation of SASS 
represents tne Department of Defense security policy, any 
security policy wnicn may be represented tnrougn a lattice 
structure Ll2] may also be implemented, Ttie NDS is invoiced 
via its extended instruction set: CLASS_E0 and CLASS_GE. Tne 
NDS is passed two classifications which it compares and then 
analyzes their relationship. CLASS_E0 will return a true 
value to the calling procedure only if the two 
classifications passed were equal. The CLASS_GE instruction 
will return true if a siven classification is analyzed to be 
either greater than or equal to another given 
classification. The NDS does not utilize a data base as it 
worts only with tne parameters it is passed. 

4. Traffic Controller 

The tast of processor scheduling is performed by the 
traffic controller. Saltzer [16J defines traffic controller 
as the processor multiplexing and control communication 
section of an operating system. The current SASS design 
utilizes Reed's [9J notion of a two level traffic 
controller, consisting of: 1) a Traffic Controller (TC) and 
2) an Inner Traffic Controller (ITC). 

The primary function of the Traffic Controller is 
the scheduling (binding) of user processes onto virtual 
processors. A virtual processor (VP) is an abstract data 
structure that simulates a physical processor through the 
preservation of an executing process' attributes (viz., tne 
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execution point and address space). Multiple VP's may exist 
for every pnysical processor in tiie system. Two VP's are 
permanently bound to Kernel processes (viz., Memory Manager 
and Idle) and as sucft are not in contention for process 
scheduling. These processes and tneir corresponding virtual 
processors are invisible to the TC. The remainine virtual 
processors are either idle or are temporarily bound to user 
processes as scheduled by the TC. The database utilized by 
the TC in process scheduling is the Active Process Table 
(APT). Figure 4 provides the structure of the APT. 

The APT is a system-wide Kernel database containing 
an entry for every user process in the system. Since the 
current SASS design does not provide for dynamic process 
creation/deletion, a user process is active for the life of 
the system. Therefore, tne size of the APT is fixed at the 
time of system veneration. The APT is logically composed of 
three parts: l) an APT header, 2) the main body of tne APT, 
and 3) a VP table. The APT header includes: 1) a LocJc to 
provide for a mutual exclusion mechanism, 2) a Running List 
indexed by VP ID to identify the current process running on 
each VP, 3) a Ready List, which points to the lintced list of 
processes which are ready for scheduling, and 4) a PlocAed 
List, Which points to the linked list of processes which are 
in the blocked state awaiting the occurrence of some event. 

A design decision was made to incorporate a single 
list of blocked processes instead of the more traditional 
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Active Process Table (APT) 
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per eventcount because of its 


notion of separate lists 
simplicity and its ease of implementation. Tdis decision 
does not appreciably affect system performance or efficiency 
as the "blociced" list will never be very long. The VP table 
is indexed by logical CPU number and specifies the number of 
VP's associated with the logical CPU and its first VP in the 
Running List. The logical CPU number, obtained during system 
initialization, provides a simple means of uniquely 
identifying each physical CPU in the system. The main body 
of the APT contains the user process data required for its 
efficient control and scheduling. NEXT_AP provides the 
linked list threading mechanism for process entries. The DBR 
entry is a handle identifying the process' Descriptor 
Segment which is employed in process switching and memory 
management. The ACCESS_CLASS entry provides every process 
with a security label that is utilized by the Event Manager 
and the Segment Manager in the enforcement of the 

Non-Discretionary Security Policy. The PRIORITY and STATE 
entries are the primary data used by the Traffic Controller 
to effect process scheduling. AFFINITY identifies the 
logical CPU which is associated with the process. VP ID is 
utilized to identify the virtual processor that is currently 
bound to the process. Finally, the EVENTCOUNT entries are 
utilized by the TC to manage processes which are blocked and 
awaiting the occurrence of some event. HANDLE identifies the 
segment associated with the event, INSTANCE specifies the 
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evenit and COUNT deterr’ines which occurrence of ihe event is 
needed. 


The Traffic Controller determines the scheduling 
order hy process priority. Every process is assigned a 
priority at the time of its creation. Once scheduled, a 
process will run on its VP until it either bioclts itself or 
it is preempted by a higher priority process. To insure that 
the TC will always have a process available for scheduling, 
there logically exists an "idle” process for every VP 
visible to the TC. These "idle" processes exist at the 
lowest process priority and, consequently, are scheduled 
only if there exists no useful worK to be performed. 

The Traffic Controller is invoiced by the occurrence 
of a virtual preempt interrupt or through its extended 
instruction set: ADVANCE, AWAIT, PHOCESS_CLASS, and 

GST_DBP._NUMBER. advance and AWAIT are used to implement the 
IPC mechanism envofced by the Supervisor. PR0CESS_C1ASS and 
GET_DBR_NDMBER are called by the Segment ^'anaffer to 
ascertain the security label and DBR handle, respectively, 
of a named process. A more detailed discussion of the TC is 
provided in chapters III and IV. 

5. Inner Traffic Controller 

The Inner Traffic Controller is the second part of 
our two-level traffic controller. Basically, the ITC 
performs two functions. It multiplexes virtual processors 
onto the actual physical processors, and it provides the 
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primitives for wnicn inter-VP communication witnin tne 
Kernel is implemented. A design cnolce was made to provide 
eacn pnysical processor in tne system vltn a small fixed set 
of virtual processors. Two of tnese VP's are permanently- 
bound to tne Kernel processes. Tne Memory Manager is tound 
to the nignest priority VP. Conversely, tne Idle Process is 
bound to tne lowest priority VP and. as a result, will only 
be scneduled if tnere exists no useful work for tne CPU to 
perform. Tne primary database utilized by tne ITC is tne 
Virtual Processor Table (VPT). Figure 5 illustrates tne VPT. 

Tne VPT is a system wide Kernel database containing 
entries for every CPU in tne system. Tne VPT is logically 
composed of four parts: l) a neader, 2) a VP data table, 3) 
a message table, and 4) an external VP list. The header 
includes a LOCK (spin lock) that provides a mutual exclusion 
mechanism for table access, a RUNNING LIST (indexed by 
logical CPU #) that identifies tne V? currently running on 
the corresponding pnysical CPU, a READ! LIST (indexed by 
logical CPU #) wnicn points to tne linked list of VP's wnicn 
are in tne "ready” state and awaiting scheduling on that 
CPU, and a FREE LIST wnicn points to tne linked list of 
unused entries in the message table. Tne VP data table 
contains tne descriptive data required by tne ITC to 
effectively manage the virtual processors. The DBR entry 
points witnin tne MMU Image to tne descriptor segment for 
the process currently running on tne VP. PRI (Priority), 
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STATE, IDLE_FLAG, and PREEMPT are tne prlnary data used by 
the ITC for VP scdeduling. PREEMPT indicates whether cr not 
a virtual preempt is pending for the VP. The IDLE_FLAG is 
set whenever the TC has bound an "idle" process to the VP. 
Normally, a VP with the IDLE_FLAG set will not be scheduled 
by the ITC as it has no useful worfc to perform. In fact, 
such a VP will only be scheduled if tne PREEMPT flag is set. 
This scheduling will allow the VP to be given (bound) to 
another process. PHYSICAL PROCESSOR contains an entry from 
the Processor Data Segment (PRDS) that identifies the 
physical processor that the VP is executing on. £iT_V?_ID is 
the identifier by which the VP is fcnown by the Traffic 
Controller. A design choice was made to nave tne EXT_VP_ID 
equate to an offset into the External VP List. The External 
VP List specifies tne actual VP ID (viz., VPT entry number) 
for each external VP identifier. This precluded tne 
necessity for run time calculation of offsets for the 
EXT_''^P_ID. NEXT READY VP provides the threading mechanism 
for the ’’Ready" linlced list, and MSG LIST points to the 
first entry in the Message Table containing a message for 
that VP. The Message Table provides storage for the messages 
generated in the course of Inter-Virtual Processor 
communications. MSG contains tne actual communication being 
passed, while SENDER identifies the VP which initiated the 
communication. NEXT_MSG provides a threading mechanism for 
multiple messages pending for a single VP. 
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The ITC is invoked by means of its extended 
instruction set: WAIT, SIGNAL, SWAP_7DBR, IDLE, SET_PREE(^PT, 
and RUNNING_VP. WAIT and SIGNAL are the primitives employed 
in implementing the Inter-VP communication. SWAP_VDBR, IDLE, 
SET_PREEMPT, and RUNNING_VP are all invoted by tne Traffic 
Controller. SWAP_VDBR provides the means by whicn a user 
process is temporarily bound to a virtual processor. IDLE 
binds the "idle” process to a VP (the implication of this 
instruction will be discussed later). SET_PREEf^PT provides 
the means of indicating that a virtual preempt interrupt is 
pending on a VP (specified by the TC) by settinff the PREEMPT 
flag for that VP in the VPT. RUNNING_VP provides the TC with 
the external VP ID of the virtual processor currently 
running on the physical processor. 

6. Distributed Memory Manager 

The Distributed Memory Manager provides an interface 
structure between the Segment Manager and the Memory Manager 
Process. This interfacing is necessitated by the fact that 
the Memory Manager Process does not reside in the 
Distributed Kernel and consequently is not included in the 
user process' address space. The primary functions performed 
in this module are tne establishment of Inter-VP 
Communication between the VP bound to its user process and 
the VP permanently bound to the Memory Manager Process, the 
manipulation of event data, and the dynamic allocation of 
available memory. The Distributed Memory Manager Module is 
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invoked ty tne Segment Manager tnrougn its extended 
instruction set: MM_CREATE_£NTR Y, MM_EEL.ETE_ENTRY. 
MM_ACTIVATE, MM_DEACTIVATE, MM_SWAP_IN, and MM_SWAP_OUT. 
Tnese extended instructions are utilized on a one to one 
basis by tne extended instruction set of the Segment Manager 
(e.g., SM_SWAP_IN utilizes (calls) MM_SWAP_IN). Wells (6J 
provides a more detailed description of tnis portion of tne 
Distributed Memory Manager and tne extended instruction set 
associated with it. 

The Distributed Memory Manager is also invoked 
tnrougn its remaining extended instructions: 
MM_RSAD_EVBNTCOUNT, MM_TICKET, MM_ADVANCE, and MM_ALLOCATE. 
These Distributed Memory Manager functions will be discussed 
in detail in chapter IV. 

E. NON-DISTRIBUTEB EERNEL 

The Non-Distributed Kernel is the second element 
residing in Level i of our abstract system view of tne SASS. 
The sole component of the Non-Distributed Kernel is the 
Memory Manager Process. 

1. Memory Manager Process 

Tne primary purpose of tne Memory Manager Process is 
the management of all memory resources within the SASS. 
These include tne local and global main memories, as well as 
the hard-disk based secondary storage. A dedicated Memory 
Manager Process exists for every CPU in tne system. Eacn CPU 
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possesses a local memory where process local segments and 
shared, non-writeable segments are stored. There Is also a 
global memory, to which every CPO has access, where the 
shared, writeable segments are stored. It is necessary to 

store these shared, writeable segments in the global memory 

to ensure that a current copy exists for every access. 

The Memory Manager Process is tasJced by other 

processes within the Kernel domain (via Signal and Walt) to 
perform memory management functions. These basic functions 
include the allocation/deallocation of local and global 
memory and of secondary storage, and the transfer of 

segments between tne local and global memory and between 
secondary storage and the main memories. The extended 
Instruction set provided by tne Memory Manager Process 
includes: CHEATE ENTRY, DELETE ENTRY, ACTIVATE, DEACTIVATE, 


SWAP_IN, and SWAP_OUT. These instructions correspond one to 
one with those of the Distributed Memory Manager Module. The 
system wide data bases utilized by all Memory Manager 
Processes are the Global Active Segment Table (G_AST), the 
Alias Table, the Dlslr Bit Map, and the Global Memory Bit 
Map. The processor local databases used by each Memory 
Manager Process are tne Local Active Segment Table (L_AST), 
and the Local Memory Bit Map. Gary and Moore [4j provide a 
detailed description of tne Memory Manager, its extended 
instruction set, and its databases. 
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A summary of tne extenctea instruction set created ty 
the components of tne Security Kernel is provided by Fii^ure 
6. One mient question tne prudence of omitting 
FHTS_PPEEMPT_HANDLER and VIRT_PHEEMPT_HANDiSH (viz., the 
handier routines for physical and virtual interrupts^ from 
the extended instruction set as both of these interrupts may 
he raised (viz., initiated) from within tne Kernel. A 
decision was made to not classify these handlers as 
’’extended instructions” since they are only executed as tne 
result of a physical or virtual interrupt and as such cannot 
be directly invoiced (viz., ’’called”) by any module in the 
system. A summary of tne databases utilized by Kernel 
modules is presented in Figure 7. 

F. SYSTEM HARDWARE 

Level 0 of the SASS consists of the system hardware. 
This hardware includes: 1) tne CPU, 2) the local memory, 3) 
the global memory, 4) the secondary storage (viz. hard 
disfc), and 5) tne I/O ports connecting tne Host computer 
systems to the SASS. Since the SASS design allows for a 
multiprocessor environment, there may exist multiple CPU's 
and local memories. The target machine selected for tne 
initial implementation of tne system is tne Zilog Z8001 
microprocessor ll7]. The Ze001 is a general purpose lb-bit, 
register oriented machine that nas sixteen 16-bit general 
purpose registers. It can directly address 8M bytes of 
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MODULE 


Segment Manager 


Event Manager 


Non-Discret ionary 
Security 

Traffic Controller 


Inner Traffic 
Controller 


DiSt rituted 
Memory Manager 


Non-Distributed 
Memory Manager 


INSTRUCTION SET 

Create_Seffment’^ 

Malce_Known’^ 

SM_Swap_In«' 

Read’*' 

Advance’*' 

Class_fiO 

TC_Advance 

Process_Class 

Signal 

Swap_VDBR 

Set_Preempt 

Running_VP 

MM_Create_Ent ry 

MM_Activate 

MM_Swap_In 

Create_Sntry 

Activate 

Swap_In 


Delete_Seffment’'' 

Terminate’*' 

SM_Swap_Out=’' 

Tldret’*' 

Awai f" 

Class_GE 

TC_Await 

Wait 

Idle 

Test_Preempt 

MM_Eelete_Entry 
MM_Deactivate 
MM_Swap_Ou t 
Delete_Sntry 
Deactivate 
Swap_0u t 


’*' Denotes user visible instructions 


Figure 6. Extended Instruction Set 
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MODULE 


DATABASE 


Gate Keeper 

Segment Manager 

Traffic Controller 

Inner Traffic 
Controller 

Memory Manager 


Parameter Table 

Known_Sesment_TaDie (KST) 

Active_Process_Table (APT) 

Virtual_Processor_Table (VPT) 

Memory_Management_Unit Image 

(MMU) 

Glo bai_Active_Segmen t_Ta bie (G_AST ) 
Local_Active_Segment_Table (L_AST) 
Di sic_Ei t_Map 
Glooal_Memory_Bit_Map 
Local_Memory_Bit_Map 


Figure 7. Kernel Databases 
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memory, extensible to 48M oytes. Tne Zfc0fe)l arcnltecture 
supports memory segmentation and two-domain operations. The 
memory segmentation capability is provided externally by the 
Zilog Z8010 Memory Management Unit (MMU). The Z 8010 MMU [ISJ 
provides management of tne Z8001 addressable memory, dynamic 
segment relocation, and memory protection. Memory segments 
are variable in size from 256 bytes to 64K bytes and are 
identified by a set of 54 Segment Descriptor Registers, 
which supply the information needed to map logical memory 
addresses to physcal memory addresses. Sach of the 64 
Descriptor Registers contains a 16-bit base address field, 
an 8-bit limit field, and an 6-bit attribute field. 
Unfortunately, tne Z8001 hardware was not available for use 
during system development. Therefore, all worlt to date has 
been completed tnrougn utilization of tne Z8002 
non-segmented version of the Z8000 microprocessor family 
[17J . Tne actual hardware used in tnis implementation is tne 
Advanced Micro Computers Am96/4116 MonoEoard Computer ll9j 
containing tne AmZ8002 sixteen bit non-segmented 
microprocessor. This computer provides 32K bytes of on-board 
RAM, 8lE bytes of PROM/ROM space, two RS232 serial I/O ports, 
24 parallel I/O lines, and a standard INTEL Multibus 
interface. Tne general structure of tne design nas been 
preserved by simulation of the segmentation hardware in 
software. Tnis software MMU Image (see Figure 8) is created 
as a database within the Inner Traffic Controller. 
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Base Addr j Limit j Attributes 


(entries for one LBR #) 


i’igure 8. Memory Management Unit (MMU) Image 
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Tne f^MU Image is a processor-iocai database indexed by 
D£R_No. Sacft DBR_No represents one record witnin tbe M!^U 
Image. Eacn record is an exact software copy of tne Segment 
Descriptor Register set in tde Hardware Each element of 
tnis software MMU Image is in tne same form utilized by tne 
special I/O instructions to load the Hardware MMU. Each DER 
record is indexed ty segment number (Segment_No). Eacn 
Seffment_No entry is composed of three fields? Ease_Addr, 
Limit, and Attributes. Base_Addr is a i6-bit field wnicn 
contains the base address of the segment in physcal memory. 
Limit is an 8-bit field tnat specifies tne number of 
contiguous bloclcs of memory occupied by tne segment. 
Attributes is an 8-bit field representing tne eight flag's 
which specify the segment's attributes (e.g., "read”, 
"execute”, "write", etc.). 

G. SUMMARY 

An extended overview of the current SASS design has been 
presented in this chapter. The four major levels of 
abstraction comprising the SASS system have been identified 
and the major components of eacn level nave been discussed. 
The extended instruction set provided by the SASS Kernel was 
also defined. With tnis bacicground, tne actual details cf 
tnis implementation will be described in chapters III and 
I?. 
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III. iMPLEMJjNTATTON ISSUES 


Issues bearing on tne implementation of process 
management and refinements made to existing modules are 
presented in tnis chapter. Process management for tne SASS 
was provided through the implementation of the Traffic 
Controller Module, the Event Manager Module, tne Distributed 
Memory Manager Module, and a Gate Keeper Stub (system trap). 
Additionally, since a demonstration/testbed was integral to 
the testing and verification of tne implementation, it was 
necessary to complete other supportive tasKs. These 
supportive tasfcs included limited Kernel database 
initialization, revised preempt interrupt handling 
mechanisms. Idle process definition and structure, and 
additional refinements to existing modules. 


A. DATABASE INITIALIZATION 

Previous vovi on SASS has relied on statically built 
databases, which proved to be sufficient for demonstration 
of a single processor, single nost supported system. In the 
current demonstration, multiple nosts are simulated, and tne 
Kernel data structures have been refined to represent a 
multiprocessor environment. Since a multiprocessor system 
was unavailable at the time of this demonstration, several 
runs” were made and traced, using different logical CPU 
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numbers, to snow tne correctness of tnis structure. Due to 
this multiprocessor representation and simulation of 
multiple nosts, tne use of statically built Kernel datata^ses 

was no longer convenient. Therefore, it became necessary to 
provide initialization routines for tne dynamic creation of 
those Kernel databases required for this implementation. 
While it was not tne intent of tnis effort to implement 
system initialization, care was talten in the writing of 
these initializing- routines so that they might be utilized 
in tne system intiaiization implementation with, hopefully, 
minimal refinement. Database initialization was restricted 
to those databases existing in tne Inner Traffic Controller 
and the Traffic Controller. Limited elements of the Known 
Segment Table (KST) and Global Active Segment Table {G_AST) 
were also created for demonstration purposes. 

1 . Inner Traffic Controller Initialization 

A "Bootstrap Loader" Module, which logically exists 
at a higher level of abstraction within tne Kernel, was 
created to initialize the databases of the Inner Traffic 
Controller. Tnis initialization includes tne creation of: 1) 
the Processor Data Segment (PRDS), 2) an MMU Map, 3) Kernel 
domain stacK segments for Kernel processes, 4) allocation 
and updating of MMU entries for Kernel processes, and 5) 
Virtual Processor Table (VPT) entries. 

The PRDS was loaded with constant values that 
specify tne physical CPU ID, logical CPU ID, and number of 
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7P's allocated to tne CPU. A design decision was made to 
allocate loffical CPU ID's in increments of two (beginning 
with zero) so that they could be used to directly access 


lists indexed by CPU number. The MMU map, constructed as a 
"byte" map, was created to specify allocated and free K.MU 
Image entries. 

A separate procedure, CR£!ATS_STACK, was created to 
establish the initial Kernel domain stacic conditions for 
Kernel processes. A discussion and diagram of these initial 
stacJc conditions is presented in tne next section. 
ALLOCATiS_MMU checks tne MMU Map and allocates tne next 
availabe MMU entry to the process being created. The PHDS is 
inserted in tne allocated MMU entry and the DJBR number is 
returned to the calling procedure. The DBH number (handle) 
is merely the offset of tne DBR in the MMU Image. Since tne 

ITC deals with an address rather than a handle, a procedure, 
GST_DBfi_ADDR, was created to convert this offset into a 
physical address. UPDATE_MMU_IMAGE is the procedure wnich 
creates or modifies MMU Image entries. DPDATE_MMU_IMAGE 
accepts as arguments the DBR number, segment number, segment 
attributes, and segment limits. To facilitate process 
switching and control, various process segments must possess 
the same segment number system wide. This is accomplished 


during 

initialization 

through 

the 

use 

of 

the 

UPDATE_ 

MMU_IMAGE procedure 

. In 

the 

ITC , 

these 

segments 

include 

the PRDS (segment 

number 

zero 

) and 

the Kernel 

stacic 


segment (segment number one). 
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Tne final tasic required in ITC iniiaiization is tne 
creation of the VPT. The VPT header is initialized with the 
’’running" and "ready" lists pointers set to a 'nil' state, 
and the "free" list pointer set to the first entry in tne 
message table. Virtual Processor entries are inserted in the 
main body of the VPT by the UPDATE_VP_TAiiLE procedure. 
Entries are first made for tne VP's permanently bound to the 
Memory Manager and Idle processes. The VP bound to the MM 
process is ^iven a priority of 2 (hiahest), and tne Vp bound 
to the Idle process is given a priority of 0 (lowest). The 
External VP ID for both of tnese VP's is set to "nil" as 
they are not visible to the Traffic Controller. The 
remaining VP's allocated to tne CPU (viz., TC visible VP's) 
are then entered in the VPT with a priority of 1 
(intermediate), and tneir "idle" and "preempt" flags are 
set. The preempt flag is set for these TC visible VP's to 
insure proper scheduling by tne Traffic Controller. Tne EBP, 
for these remaining VP's is initialized with the Idle 


process DBR. A discussion 

of "idle 

processes 

and VP's 

will 

be provided later 

in this 

Chapter. 

The External 

VP 

ID 

for 

each TC visible 

VP is 

merely 

tne offset 

of 

the 

next 


available entry in tne EXTERNAL VP LIST. This External VP ID 
is entered in tne VPT, and tne corresponding VP ID (viz., 
VPT Entry #) is entered in the EXTERNAL VP LIST. 

Once tnese VPT entries nave been made, it is 
necessary to set the state of each VP to "ready” and thread 
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tnem (by priority) into tne appropriate ready list. A VPT 
threading mechanism was provided by Reitz [5j in procedure 
MAKE_READY. However, it was desired to nave a more general 
threading mechanism that could be used for other lists. 
Procedure LlST_INS£ItT was created to provide this general 
threading mechanism. LIST_INSERT is logically a "library" 
function that exists at tne lowest level of abstraction in 
tne Kernel. This function threads an object into a list 
(specified by the caller) in order of priority, and tnen 
sets its state as specified by tne calling parameters. 

Once tne "Bootstrap Loader" nas completed ITC 
initialization, it passes control to tne ITC GETWOHK 
procedure to begin VP scheduling. 

2. Traffic Controller Initialization 

The initialization routines for tne TC include 
TC_INIT, . CREATE_PROCESS, and CREATS_KST. These routines are 
called from tne Memory Manager process. Tne MM process was 
chosen to initiate these routines as it is bound to tne 
highest priority VP and will begin running immediately after 
the Inner Traffic Controller is initialized. Procedure 
MM_ALLOCATE was written to allocate memory space for data 
structures during initialization (viz.. Kernel stacics, user 
stacks, and KST's). Memory space is allocated in blocKs of 
100 (hex) bytes. MM_AILOCATE is merely a stub of the memory 
allocating procedure designed by Moore and Gary l4j . 
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It was necessary to pass long lists of arguments to 
tne TC for initialization purposes. To ail in tnis passing 
of parameters, a data structure template was used. This 
template was created toy declaring tne parameters as a data 
structure in both tne sending and receiving procedures, and 
then imaging this structure at absolute address zero. The 
process' stacK pointer was tnen aecremented cy tne size of 
the parameter data structure, and the parameters were loaded 
into tnis data structure indexed by tne stact pointer. Tnis 
template made it very easy to send and receive lon^ argument 
lists using tne process' staci segment. 

TC_INIT initializes tne APT header and virtual 
interrupt vector (discussed later). Each element of tne 
running list is marlced "idle", tne ready and blocked lists 
are set to "nil", and tne number of VP's and first VP for 


eacn CPU 

a re 

entered in tne 

VP table. 

The 

addre 

ss of the 

virtual 

preempt 

handler is then 

passed to 

the 

ITC 

procedure 

create_ 

int 

_VEC 

for insertion 

in tne 

vir 

tual 

interrupt 


vector. 

CREATE_PR0CESS intializes user processes and creates 
entries in the APT. ALLOCATE_MMU is called to acquire a DPR 


number. 

and 

an APT 

entry is 

created with 

tne 

process 

descriptors 

(viz., pa 

rameters). 

Tne process is 

then 

declared 

#• ft 

ready 

and 

threaded 

into tne 

appreciate ready 

list by 

calling 

the 

threading 

function, 

LIST_INSERT. A 

user 

stack is 


allocated and UPDATE MMU IMAGE is called to include tne user 
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stack in the MMU as segment number three. The user stack 
contains no information or user process initialization 
parameters (viz., execution point and address space) as ail 
processes are initialized and begin execution from the 
Kernel domain. Next, a Kernel domain stack is allocated and 
included in the MMU Image. A aesign decision was made to 
initialize the Kernel stacks for user processes with tne 
same structure as the Kernel process' stacks. The rationale 
for this decision is presented in tne next section. As a 
result of this decision, it became possible to use the 
CREATE_STACK procedure in buiIding^ Kernel domain stacks for 
both Kernel and user prosesses. CHEATE_STACK was therefore 
used as a library function and placed in the library module 
with LIST-INSERT. 

Finally, a Known Segment Table (KST) stub is created 
to provide a means of demonstrating the mechanism provided 
by the eventcounts and sequencers for interprocess 
communication (IPC) and mutual exclusion. Space for the 
process' KST is created by calling MM_ALLOCATE. The KST is 
then included in the process' address space, as segment 
number two, by UPDATE_MMU_IMAGE. initial entries are made in 
the Known Segment Table by procedure CR£ATE_KST. CREaTE_KST 
makes an entry in the KST for the "root" and marks the 
remaining KST entries as "available." Tne Unique_ID portion 
of the root's handle (viz., upper two words) is initialized 
as -1 (for convenience) and tne G_AST entry number portion 
of the handle (viz., lowest word) is initialized with zero. 
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3. Additional Initialization Reouirements 


As already mentioned, the (Memory Manager Process 
prepares tne arguments utilized oy TC_INIT, CR£ATE_PP.CC£SS , 
and CREATE_KST for TC initialization and user process 
creation. Additionally, tiie MM process creates a Global 
Active Segment Table (G_AST) stub utilized for demonstration 
of event data management. The G_AST stub is declared in a 
separate module (viz., the DEMO_DATABASE Module) with the 
format prescribed by Moore and Gary l4j. However, the only 
fields initialized and utilized by this implementation are 
UNI0UE_ID, SEQUENCER, INSTANCE 1, and INSTANCE 'B. The 
eventcounts and sequencer fields are initialized as zero 
whenever an entry is created in the G_AST. The UNICUE_IE is 
created Just to support this demonstration and does not 
reflect the segment's unique identifier as specified by 
Moore and Gary [4j . In this demonstration, UNIOUE_IIi is 
built with the parameters passed to MM_ACTIVATE. The first 
word in UNI0UE_ID is the G_AST entry number of the segment's 
parent, and the second word is the segment's entry number 
into tne alias table. The UNI0UE_ID togetner with tne offset 
of the segment's entry in the G_AST comprise the segment 
HANDLE maintained in tne EST. Tne first entry in tne G_AST 
is reserved for the root, and is initialized with an 
Unique_ID of minus one (-1). It should be noted that any 
call to MM_ACTIVATE for a segment already possessing an 
entry in the G_AST will not effect any cnanges to that 
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entry. Tills is to insure tnat a single &_AST entry exists 
for every seffment as specifiea by lYoore and. Gary • 


B. PREEMPT INTERRUPTS 

Various refinements were made in tile handlins of botn 
pnysical (nardware) and virtual (software) preempt 
interrupts, A hardware preempt is a non-vectored interrupt 
tnat invokes tne virtual processor scneduling mecnanism 
(viz., ITC GETWORK). A virtual preempt is a software 
vectored Interrupt tnat invokes tne user process scheduling 
mechanism (viz., TC_G£TWORK). This implementation provides 
tne notion of a virtual interrupt tnat closely mirrors tne 
behavior of a hardware interrupt. In particular, there are 
similar constructs for initialization of a handler, 
invokation of a handler, masking of interrupts, and return 
from a handler. As with most nardware interrupts, a virtual 
interrupt can occur only at tne completion of execution for 
an "instruction,” where each Kernel entry and exit for a 
process delimit a single "virtual instruction." 

1, Physical Preempt Handler 

•Tne pnysical preempt nandler resides in tne virtual 
processor manager (viz.. Inner Traffic Controller). The 
functions it perform are: l) save tne execution point, H) 
invoke ITC GETWORK, 3) check for virtual preempt interrupts, 
4) restore tne execution point, and 5) return control via 
the IRET instruction. Reitz I5j included the nardware 
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preempt nanaler in ITC GETWORK by estabiisning two entry 
points and two exit points, one for a regular call to 
GETWORK and another for the preempt interrupt. He had a 
separate procedure, TEST_PREEMPT, that was used to checi for 
the occurrence of virtual preempt interrupts. This structure 
worfcs nicely, hut it requires some means of determining how 
GETWORK was invoiced so that the proper exiting mechanism is 
used. This was resolved by incorporating a preempt interrupt 
flag in the status register blocK of every process' Kernel 
domain stacS segment. A design decision was made to 
restructure the hardware preempt handler into a single and 
separate procedure, PH"^S_PRfiEMPT_HANDLER. This allowed ITC 
GETWORK to have a single entry and exit point, and it did 
away witn the necessity of maintaining a preempt Interrupt 
flag in the process stacics. PKIS_PRE£MPT_PANELSR was 
constructed from the preempt handling code in GETV/OPK and 
procedure TEST_PREEMPT. TEST_PREEp:PT was deleted from the 
ITC as its functions were performed by FHYS_PRESMPT-HANELER. 

A further refinement was made to the hardware 
preempt handler dealing with the method by wnich tne virtual 
preempt handler was invoked. Reitz [5j invoiced the virtual 
preempt handler from TEST_PREEMPT oy means of tne "call" 
instruction. Since the virtual preempt handler logically 
exists at a nigner level of abstraction than the ITC, tnis 
invocation violated our notion of only allowing "calls" to 
lower or equal abstraction levels. However, this deviation 
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was necessiiaied by tiie absence of a virtual interrupt 
structure. Tnis problem was alleviated by creating a virtual 
interrupt vector in tne ITC tnat is used in tne same way as 
tne Hardware interrupt vector. Tne virtual preempt was ^iven 
a virtual interrupt number (zero). Tne virtual interrupt 
Handler is tnen invoiced by means of a "jump" tnrous^ tne 
virtual interrupt vector for virtual Interrupt number 0. 
Tnis invocation occurs in tne same manner tnat tne nandlers 
for Hardware interrupts are invoked. The virtual interrupt 
vector is created by procedure CREATi’_INT_V£C. 
CREATE_INT_'7EC accepts as arguments a virtual interrupt 
number and tne address of tne interrupt Handler. Tne 
creation of tne virtual preempt entry in tne virtual 
interrupt vector is accomplished at the time of the Traffic 
Controller initialization by TC_INIT. 

2 . Virtual Preemut Handler 

Tne virtual ureempt Handler (VIRT_PRSE^'PT_HANLLER ) 
resides in the user process manaeer (viz., the Traffic 
Controller). The functions performed by VIRT_FREEMPT_EANDLER 
are: 1) determine tne VP ID of tne virtual pro'^essor bein? 
preempted, 2) invoke tne process scheduling mechanism (viz., 
TC_GETWORK), and 3) return control via a virtual interrupt 
return. Tne correct VP ID is obtained by calling RUNNING_VP 
in the ITC. The Active Process Table is then locked, and tne 
state of tne process running on tnat VP is changed to 
"ready." At tnis time, process scnedulins is effected by 
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calling" TC_C-£TWORK. Once process scneduiing is compietei, 
the APT is unlociced and control is returned via a virtual 
interrupt return. This virtual interrupt return is merely a 
Jump to the PP.SEMFT_P£T label in the hardware preempt 
handler (This jump emulates the action of the IRET 
instruction for a hardware interrupt return). This latel is 
the point at which the virtual preempt interrupts are 
unmasRed. 

All Kernel processes are initialized to appear as 
though they are returning from a hardware preempt interrupt. 
All user processes initially appear to be returning from a 
virtual preempt interrupt. Therefore, tne initial conditions 
of a process' Kernel domain stacR is largely influenced dv 
tne stacK manipulation of the preempt handlers. Figure 9 
illustrates the initial Kernel domain stacit structure for 
ail system processes. 

The Initial Kernel Flag Control Word (FCW) value is 
" 5000 ", indicating non-segmented code, system mode of 
operation, non-vectored interrupts mashed, and vectored 
interrupts enabled. The Current StacK Pointer value is set 
to the first entry in the stach (viz., SP). The IRET Frame 
is tne portion of tne Kernel stacJc affected by tne IRET 
instruction. The first element. Interrupt ID (set to "FFFF”) 
is merely popped off of tne stach and discarded. The next 
element. Initial FCW, is popped and placed in tne system 
Flag Control Word. Initial FCW is set to "5000" for Kernel 
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processes and (indicating normal mcae witn ail 
interrupts enabled) for user processes. Tne final element of 
tne IRET frame. Initial IC is popped off of tne stacK and 
placed in tne program counter (PC^ register. Tnis value is 
initialized as tne entry address of tne process in Question. 

The "register" entries on the stacK represent the 
initial register contents for tne process at tne beginning 
of its execution. Since tne Kernel processes (viz., MM and 
Idle) do not require any specific initial register states, 
their entries reflect the register contents at the time of 
stacK creation. Initial register conditions are used to 
provide initial "parameters" required by the user processes. 
This will depend largely upon tne parameter passing 
conventions of tne implementation language. Tne means for 
register initialization was provided through CREATE_PECCSSS; 
however, the only initial register condition used for tne 
user processes in this demonstration was register #13. 
Register #13 was used to pass tne user ID/Host number of tne 
process created. This value is utilized by the user process 
in activating the segment used for inter-process 
communication between a Host's File manager and I/O 
processes. Another logical parameter passed to the user 
processes is the root segment number. Tnis did not require a 
register for passing in tne demonstration as it is known to 
be the first entry in the KST for all processes. The W_S_P 
entry on tne stack represents tne initial value of the 
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normal stacK pointer. For user processes, tnis value is 
obtained wnen tne Supervisor domain stacit for tnat process 
is created. For Kernel processes, this value is set to 
"FFFF" since tney execute solely in the Kernel domain and 
have no Superivsor domain stack. The Preempt Return Point 
specifies tne address wnere control will be passed once tne 
process' V? is scheduled and the "return” from ITC GETWORK 
is executed. For Kernel processes, tnis is tne point within 
the hardware preempt handler where tne virtual processor 
table is unlocked. For user processes, tnis is tne point 
within tne virtual preempt handler where tne Active Process 
Table is unlocked. 

It is important to note that if tne APT was not 
unlocked when a user process be^an its initial execution, 
the system would become deadlocked and no further process 
scheduling* could occur. It should be further noted that the 
initial stack conditions for user processes do not reflect a 
valiji history of execution. The "normal" history of a user 
process returnini? from ITC GETWOPK after a virtual preempt 
interrupt would reflect the passinsr of control through 
S’it’AP_VD3R and TC_GETWORK to the point in tne virtual preempt 
handler where the APT is unlocked. Another "possible" 
history could reflect tne occurrence of a hardware preempt 
interrupt at the point in the virtual preempt handler where 
tne APT is unlocked. Sucn a history would be depicted by 
replacing the current top of the stack with the return point 
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into the hardware preempt handler (viz., at the point of 
virtual preempt interrupt unmaslcing) and an additional 
nardware preempt interrupt frame wnose IC value in the IHET 
frame is the point in tne virtual preempt handler where tne 
APT is unlocked. The current initial stack condition for 
user processes was cnosen for its ease of understanding and 
its clear depiction of the fact that tne structure of a 
Kernel domain stack is the same for both Kernel and user 
processes. 

C. IDL2 PROCESSES 

In tne SASS design, there logically exists a Kernel 
domain "idle” process for every physical processor in the 
system and a Supervisor domain "idle" process for every "TC 
visihle" virtual processor in the system. These processes 
are necessary to insure that both tne VP scheduler (viz., 
ITC GBTWORK) and the process scheduler (TC_C£TW0RK) will 
always nave some object to schedule, hence precluding any 
CPU or VP from ever having an undefined execution point. 
Since the Kernel domain Idle process performs no useful 
work, it could be included within the ITC by means of an 
infinite looping mechanism. The Kernel Idle process was 
maintained separately, however, as it is hoped that future 
work on SASS will provide this Idle process with some 
constructive purpose (e.^., performing maintenance 
diagnostics). 


71 








































The Supervisor aonain Idle processes (nereafter referred 
to as TC Idle processes) are scneduled (bound) on VP's when 
there are no user processes awaiting scheduling. Since a TC 
Idle process performs no user constructive worlc, we do not 
want any VP executing a TC Idle process to be bound to a 
physical processor. In other words, a VP bound to a TC Idle 
process assumes the lowest system nriority (represented by 
the "idle fla^"). Therefore, any such VP will have its idle 
flag set and will not be scneduled unless it receives a 
virtual preempt interrupt. Such an interrupt will allow the 
V? to be rescheduled by the Traffic Controller. It should be 
obvious, at this point, that a TC Idle process will never 
actually be^in execution on a real processor. This knowledge 
allowed a design decision to be made to only simulate the 
existence of TC Idle processes. At tne TC level, this was 
accomplished by a constant value, IDLS_PP.OC, that was used 
as a process ID in tne APT running list, thus precluding tne 
necessity of any "idle" entries in the APT. At the ITC 
level, any VP marked "idle" (viz., tne idle flag set) was 
given tne DPR number (viz., address space) of the Kernel 
Idle process solely to provide tne use of a Kernel domain 
stack for rescheduling of the VP. 

D. additional KERNEL REFINEMENTS 

In addition to those already discussed, several other 
refinements to existing Kernel modules were effected in this 
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irrplementation. One of inese refinerrents deals witn tne way 
virtual processors are identified fcy tne Traffic Controller. 
In the current inplenentation, all TC visible virtual 
processors are ^iven an External VP ID which corresponds to 
its entry nurrher in an External VP List. This required a 
modification to the ITC procedure PUNNING_VP. The benefits 
derived from this refinement included the ability to 
directly access the External VP ID in tne Virtual Processor 
Table vice the requirement of a run time division to compute 
its value and the ability to use the External V? ID as an 
index into the TC running list. 

Refinements were also made to the existing Memory 
manager. File i^anager, and 10 process stubs used for 
demonstration purposes. These refinements were largely 
associated with tne eventcount and sequencer mecnanisms 
utilized in this implementation. The current status of these 
processes is provided in a report by Scneil and Cox [ 22 ]. 

The remaining refinements deal largely with the MMU 
Image. In Moore and Gary's [4J design, tne MMU Image was 
managed by the Memory Manager process. This was largely 
because tne MMU Image is a processor local database and 
would seem well suited for management by the non-distributed 
Kernel. In fact, tne MMU Image is utilized mainly by tne ITC 
for the multiplexing of process address spaces. Therefore, 
in the current design, tne MMU Images are maintained by the 
Inner Traffic Controller. However, the MMU header proposed 
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by Moore ana Gary (vi 2 .. tr.e BLCCKS_USED ana 
MAXIMUM_AVAI LABLE_^EL0CSS t’ieias) was retainei in the Memory 
Manarer as it is usea strictly in tne management of a 
process' virtual core and is not associated with the 
hardware MMU. 

In ’'^ells' design [6J , the Traffic Controller used tne 
linear ordering of tne DfR entries in the MMU Image as the 
D2R handle (viz., 1,2,3...). This required a run time 
division operation to compute the DBR number, and a run time 
multiplication operation, by MM_GET_DBR_VALUE, to recompute 
the EER address for use by the ITC. In the current design, 
the offset of the ERR entry in the MMU Image (obtained at 
the time of MMU allocation) is used as tne ERR handle in the 
Traffic Controller. Furthermore, SWAF_VESR was refined to 
accept a EBR handle rather than a EBR address to preclude 
the necessity of the Traffic Controller having to deal with 
MMU addresses. EBR addresses are computed only within the 
ITC (viz., by procedure GET_EBR_ABER) by adding the value of 
the EBR handle to the base address of the MMU Image. Since 
EBR addresses are now used solely within tne ITC. procedure 
MM_GET_EBR_VALUE was no longer needed and was deleted from 
the Memory Manager. 

E. summary 

The primary issues addressed in this thesis effort have 
been presented in this chapter. Aside from the process 
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niandiPement functions, tnis description included a mecnanism 
for limited Kernel dataoase initialization, a revised 
preempt interrupt Handling mecnanism, tne creation of a 
virtual interrupt structure, a definition of "idle" 
processes and tneir structure, and a discussion of tne minor 
refinements effected in existing SASS modules. A detailed 
description of tne implementation of process management 
functions for tne SASS is presented in tne next chapter. 
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17. PROCESS MANAGEMJilNT IMPLEUSNTATICN 


Tiie implementation of process management functions and a 
gate deeper stub (system trap) is presented in tnis cnapter. 
Tne implementation is discussed in terms of tne Event 
Manager, Traffic Controller, Distributed Memory Manager, 
User Gate, and Kernel Gate Keeper modules. A tloclc diagram 
depicting tne structure and interrelationsnips of these 
modules is presented in figure 10. Support in developing tne 
ZS0O0 machine code for tnis implementation was provided by a 
Zilog MCZ Developmental System operating under the RIO 
operating system. The Developmental System provided dislc 
file management for a dual drive, hard sectored floppy disic, 
a line oriented text editor, a PLZ/ASM assembler, a linker 
and a loader tnat created an executable image of each Z80OO 
load module. An upload/download capability with tne 
Am96/4116 MonoBoard computer was also provided. This 
capability, along witn tne general interfacing of tne 
Am96/4116 into the SASS system, was accomplished in a 
concurrent tnesis endeavor by Gary Baker. Baker's work 
relating to hardware initialization in SASS, will be 
published upon completion of nis tnesis work in June 1981. 
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Implementation l^odule 


S tructure 


77 
















































A. EVENT MANAGER MODULE _ 

The eventcouni and sequencer primitives Ll5J, which are 
system-wide oDjects, collectively comprise the event data of 
SASS. As mentioned earlier, this event data is tied directly 
to system segments and is stored in the Global Active 
Segment Table. There are two eventcounts and one sequencer 
for every segment in the system. These objects are 
identified to the Kernel in user calls by specification of a 
segment number. Once this segment number is identified by 
the Kernel, tne segment's handle can be obtained from tne 
process' Known Segment Table. The segment handle identifies 
the particular entry in tne G_AST containing tne event data 
desired. 

Tne Event Manager module manages tne event data within 
the system and provides tne mecnanism for interprocess 
communication between user processes. The Event Manager 
consists of six procedures. Four of these (Advance, Await, 
Read, and TicKet) represent tne four user extended 
instructions provided by the Event Manager. The remaining 
two procedures provide internal computational support to 
include necessary security cneclcing. The Event Manager is 
invoked solely by user processes, via tne Gate Keeper, 
through utilization of the extended instruction set 
provided. For every Event Manager extended instruction 
invoiced by a user process, the non-discretionary security is 
verified by comparing the security access classification of 
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tne process invoking tne instruction witn tne classification 
of tne object (segment) being accessed. Access to the user 
process' Known Segment Table is required by tne module in 
order to ascertain tne segment nandle and security class for 
a ffiven segment number. The PLZ/ASM assembly language 
listing for tne Event ^'anager module is provided in Appendix 
A. A more detailed discussion of tne procedures comprising 
tne Event Manager follows. 

1. Support Procedures 

The procedures GET_HANEL£ and CONVERT_AND_VEEIIY 
provide internal support for tne Event Manager anc are not 
visible to tne user processes. Procedure CONVEP.T_AND_VEF.IFY 
is invoked by tne four procedures representing the 
instruction set of the Event Manager. The input parameters 
to CON^SP,T_AND_VEP.IFT are a segment number and a requested 
mode of access (viz., read or write). CONVERT_AND_VER1FY 
returns a pointer to tne segment's handle and a success 
code. Procedure GET_HANDLE is invoked solely by 
CONVERT_AND_VEPIFT. The input parameter to GET_HANDLE is the 
segment number received as input by CONVERT_AND_VSRIFY. 
GET_HANDLE returns a pointer to tne segment's handle, a 
pointer to tne segment's security classification, and a 
success code. A discussion of the functions provided by 
these support procedures follows. 

Procedure GET_HANDL.E translates tne segment number, 
received as input, into a KST index number and verifies that 
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tne resuiiin^ index number is valid. Next tne base address 
of tne process' KST is obtained from procedure 
ITC_GET_SEG_PTR. Tne KST index number is tnen converted into 
a KST offset value and added to tne base address to obtain 
tne appropriate KST entry pointer for tne seicment in 
question. A verification is tnen made to insure that tne 
referenced seg’ment is "icnown" to tne process. If tne segment 
is not Known, an error message is returned to 
CONVKRT_AND_VERIFY. Otnerwise, a pointer to tne se,sment's 
nandle is obtained to identify tne segment to tne memory 
manager. A pointer to tne segment's security class entry in 
the KST is also returned for use in appropriate security 
cnecKs. 

Procedure CONVERT_AND_VERIFY provides tne necessary 
non-discretionary security verification for tne extended 
instruction set of the Event Manager. Procedure GET_fiANDLE 
is invoiced for segment number verification and to obtain 
pointers to the segment's handle and security class. If 
G£T_HANDLE returns witn a successful verification, tne 
process' security class is compared to tne segment's 
security class to verify tne mode of access requested. A 
request for "write" access causes invocation of tne CLASS_E0 
function in tne Non-Discretionary Security Module to insure 
that the security classification of tne process is equal to 
the classification of the eventcount or sequencer, which is 
the same as that of tne segment. Otnerwise, tne CLASS GE 






































































function is called to verify tnat tne process Has read 
access. If tne appropriate security cnecK is unsuccessful, 
an error code is returned by CONVSP.T_AND_VERIFY. Otherwise, 
tne segment handle is returned along with a success code of 
"succeeded" indicating that tne user process possesses the 
necessary security clearance to complete execution of tne 
extended instruction. 

2. Read 

Procedure READ ascertains tne current value of a 
user specified eventcount and returns its value to the 
caller. Tne input parameters to READ are a segment number 
and an instance (viz., an event number). C0NVERT_AND_7ERIFT 
is invoiced with a "read" access request to obtain tne 
segment's handle and necessary verification. "Read" access 
is sufficient for tnis operation as it only requires 
observation of tne current eventcount value and performs no 
data modification. If verification is successful, procedure 
MM_READ_EVSNTCOUNT is called to obtain the eventcount value. 

3. TicKet 

Procedure TICKET returns tne current sequencer value 

for the segment specified by the user. C0NVERT_ANE_VER1FY is 

called with a request for write access to obtain 

verification and the segment handle. Write access is 

required because once tne sequencer value is read it must be 

incremented in anticipation of the next ticicet request. Once 

■% 

verification is complete, MM_TICKET is invoiced to obtain the 
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sequencer value that is returned to tne user process. It is 
noted tnat every call to TICKET for a particular segment 
number will return a unique and time ordered sequencer 
value. This is because tne sequencer value may oniy oe read 
within M^'_TICK£T while the G_AST is Incited, thereby 
preventing simultaneous read operations. Futhermore, once 
the sequencer value is read it is incremented before the 
G_AST is unloclted. 

4. Await 

Procedure AWAIT allows a user process to blocfc 
itself until some specified event has occurred. The 
parameters to AWAIT include a segment number and instance, 
which identify a particular event, and a user specified 
value which identifies a particular occurrence or the event. 
Verification of read access and a pointer to tne segment's 
handle is obtained from procedure C0N7£RT_AND_VEHIFY . 
Procedure TC_AWAIT is invoiced to effect the actual waiting 
for the event occurrence. TC_AWAIT will not return to AWAIT 
until the requested event has occurred. It is noted that 
AWAIT maKes no assumptions about the event value specified 
by the user. Therefore, the Kernel cannot guarantee that the 
event specified by the user will ever occur, this is the 
responsibility of other cooperating user processes. 

b. Advance 

Procedure AL'VanCE allows a user process to broadcast 
the occurrence of some event. This is accomplished by 
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incrementing tne value of tne eventcount associatea witn tne 
event tnat has occurred. The parameters to ADVANCE include a 
segment number and instance wnich identify a particular 
event. The calling process must nave write access to the 
identified segment as modification of the eventcount is 
required. Verification of write access and a pointer to tne 
segment's handle is obtained through procedure 
CON VERT_AND_'/ERIFY. Procedure TC_ADVANCE is invoiced to 
perform the actual broadcasting of event occurrence. 

E. traffic controller module 

The primary functions of the Traffic Controller module 
are user process scheduling and support of tne inter-process 
communication mechanism. The Traffic Controller is invoiced 
by tne occurrence of a virtual preempt interrupt and ty tne 
Event Manager and the Segment Manager tnrougn tne extended 
instruction set: TC_Advance, TC_Await, Process_Class ♦ and 
Get_DER_NUMBSR. The Traffic Controller module is comprised 
of nine procedures. Four of these procedures represent tne 
extended instruction set of tne Traffic Controller. A 
detailed discussion of six of tne proceaures contained in 
the Traffic Controller module is presented below. The 
remaining three procedures (viz., TC_INIT, CREATE_?RCCESS , 
and CREATE_f:ST) were described in chapter three. The PLZ/ASM 
assembly language source code listings for tne Traffic 
Controller module is provided in Appendix £. 
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1. TC Geiworlt 


Procedure TC_GETWOEK provides me mecnanism for user 
process scdedulin^. Tde input parameters to TC_GSTWORK are 
tne VP ID of tne virtual processor to vnicn a process will 
be scheduled and the logical CPU number to which the virtual 
processor belongs. The determination of which process to 
schedule is made by a looping mechanism that finds the first 
"ready" process on the ready list associated with the 
current logical CPU number. Processes appear in the ready 
list by order of priority. This looping mechanism is 


required as both running and ready processes are 
maintained on the ready list. This ready list structure was 
Chosen to simplify tne algorithm provided in procedure 
TC^Advance. If a ready process is found, its state is 
Changed to "running" and its process ID (viz., tne APT entry 
number) is inserted in tne running list entry associated 
with tne current virtual processor. Procedure S'>IAP_VDBR is 
then invoiced in the Inner Traffic Controller to effect the 
actual process switch. If a ready process was not found 
(viz., the ready list was empty or comprised solely of 
"running processes"), tnen tne running list entry associated 
with the current virtual processor is marked with the 
constant ”ldie_Proc" and procedure IDLE is invoiced in tne 
Inner Traffic Controller. 
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2 . TC Await 


Tue primary function of TC_AWAIT is tne 
determination of wtietiier some user specified event nas 
occurred. If tne event nas occured, control is returned to 
tne caller. Otnerwise, tne process is Oiocied and anctner 
process is scneduled. Tne input narameters to TC_AWAIT are a 
pointer to a segment nandlet an instance (event number), and 
a user specified eventcount value. TC_AWAIT initially locks 
tne Active Process Table and obtains tne current value of 
tne eventcount in question by calling procedure 
MM_RSAD_S?ENTCCUNT. The determination of event occurrence is 
made by comparing tne user specified eventcount value witn 
the current eventcount. If tne user value is less tnan cr 
equal to tne current eventcount, tne awaited event nas 
occurred and control is returned to tne caller. Otnerwise, 
tne awaited event nas not yet occurred and tne process must 
be blocked. 

If the process is to be blocked, procedure 
RUNNING_VP is invoked to ascertain tne VP ID of tn® virtual 
processor bound to the process. The process' ID (viz., APT 
entry number) is then read from the running list. T.he input 
parameters to TC_A'«>IAIT (viz.. Handle, Instance, and Valued 
are then stored in tne Event Data portion of the process' 
APT entry. Tne process is removed from its associated ready 
list by redirecting the appropriate linking threads 
(pointers). Once removed from tne ready list, tne process is 
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threaded into the biocJced list and its state changed to 
"biociced" by invocation of the library function LIST_INSERT. 
Procedure TC_GfiTWORK is then called to schedule another 
process for the current virtual processor. 

3. TC Advance 

The primary purpose of TC_ADVANCE is the 
broadcasting of some event occurrence. This entails 
incrementing the eventcount associated with the event, 
awakening ail processes that are waiting for the event, and 
insuring proper scheduling order by generating any necessary 
virtual preempt interrupts. Tne nign level design algorithm 
for TC_ADVANCE is provided in figure 11. The input 
parameters to TC_ADVANCE are a pointer to a segment's handle 
and an instance (event number). Initially, TC_AD?ANCE locks 
tne APT to prevent tne possibility of a race condition. Tne 
eventcount identified by the input parameters is then 
incremented by calling MM_ADVANCE. MM_ADVANCS returns tne 
new value of the eventcount. Once the eventcount has been 
advanced, TC_ADVANCE awakens all processes awaiting tnis 
event occurrence. This is accomplished by checking all 
processes that are currently in tne blocked list. The 
process' HANDLE and INSTANCE entries are compared with the 
handle and instance identifying tne current event. If tney 
are the same, then tne process is awaiting some occurrence 
of tne current event. In sucn a case, tne process' VALUE 
entry in the APT is compared with the current value of the 
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TC_ADVANCL‘ Procedure (HANDLi:, INSTANCE) 
Ee^in 

! Get new eventcount ! 

COUNT := MM_ADyANCE (HANDLE, INSTANCE) 

Cali WAIT.LOCK (APT) 

! VaAe up processes ! 

PROCESS := BLOCKED LIST HEAD 


Do wniie not end of BLOCKED_LIST 
If (PROCESS.HANDLE = HANDLE) and 

(PROCESS.INSTANCE = INSTANCE) and 
(PROCESS.COUNT <= COUNT) 
then 

Call LIST_INSERT(READI LIST) 
end i f 

PROCESS ;= PROCESS.NEXT_PROCESS 
end do 

! Cnect ail ready lists for preempts ! 
LOGICAL_CPU_NO := 1 

Do wniie LOGICAL_CPU_NO <= #NR_CPU 
! Initialize oreempt vector ! 
yP_ID := ?IRST_VP(LOC-ICAL_CPU_NO) 

Do for LOOP := 1 to NR_7P(LOGICAL_CPU_NO 
RUNNING_LIST[VP_IDj.PREEMPT := #TRUE 

VP_ID := VP_ID + 1 
end do 

! Find preempt candidates ! 

CANDIDATES := 0 

PROCESS := READY LIST HEAD(LOGICAL CPU NO) 


Figure 11 


TC_AD?ANCE Algoritnrr 







































VP_ID := FIRST_7P{L0GICAL_CPU_N0) 

Do (for CYCLP = 1 to NH_VP(LOGICAL CPU NO) and 
not end of READr_LIST(LCGICAL_CPU_NO) 

If PROCESS = #RUNNING 
then 

HUNNING_LIST17P_IDJ .PREEMPT := *#FALSE 
else 

CANDIDATES := CANDIDATES 1 
end i f 

yp_ID := VP_ID + 1 
PROCESS := PROCESS.NEXT_PROCESS 
end do 

! Preempt appropriate candidates ! 

7TJ_ID := FIRST_VP(LOGICAL_CPU_NO) 

Do for CHECK := 1 to NR_7P(LOGICAL_CPU_NO> 

If (RUNNING LIST[7P_IDJ .PREEMPT = #=TRUE) and 
(CANDIDATES > 0) 
tnen 

Call SET_PREEMPT(7P_ID) 

candidates := CANDIDATES - 1 
end i f 

VP_ID := 7P_ID + 1 
end do 

L0GICAL_CPU_N0 := LOGICAI_CPU_NO + 1 
end do 

Call UNLOCK(APT) 

Return 

End TC ADVANCE 


Figure li. TC_AD7ANCE Algoritnm (Continued) 
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eventcount. If tne process' VALUE is less tnan or equal to 
tne current eventcount value, tne awaited event nas occurred 
and tne process is removed from tne Dlocired list and 
tnreaded into the appropriate ready list ty tne litrary 
function LIST_INSERT. 

Once tne bloclced list nas been checied, it is 
necessary to reevaluate eacn ready list to insure tnat tne 
nignest priority processes are running. It is relatively 
simple to determine if a virtual preempt interrupt is 
necessary, nowever, it is considerably more difficult to 
determine whicn virtual processor snould receive the virtual 
preempt. To assist in tnis evaluation, a "count" variable 
(number of preempts needed) is zeroed and a preempt vector 
is created on the Kernel stacit with an entry for every 
virtual processor associated with tne logical CPU being 
evaluated. Initially, every entry in tne preempt vector is 
mariced "true" indicating tnat its associated virtual 
processor is a candidate for preemption. Once the preempt 
vector is initialized, tne first ”n” processes on tne ready 
list (where n equals the number of VP's associated with the 
current logical CPU) are checked for a determination of 
their state. If a process is found to be "runninfi-" then it 
should not be preempted as processes appear in tne ready 
list in order of priority. When a running process is found, 
its associated entry in tne preempt vector is marked 
’false.” If a process is encountered in tne "ready” state 
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then it should be running and the "count" variable is 
incremented. Wnen tne first "n" processes nave been cnecited 
or when we reach the end of the current ready list 
(whichever comes first), the entries in tne preempt vector 
are "popped” from tne stacic. If an entry from the preempt 
vector is found to be "true”, this indicates that its 
associated virtual processor is a candidate for preemption 
since it is either bound to a lower priority process, or it 
is "idle." In such a case, tne "count” variable is evaluated 
to determine if the virtual processor associated with the 
vector entry should be preempted. If tne count exceeds zero, 
a virtual preempt interrupt is sent to the V? and the count 
is decremented. Otherwise, no preempt is sent as tnere is no 
higher priority process awaiting scheduling. 

This preemption algorithm is completed for every 
ready list in the Active Process Table. Once all ready lists 
nave been evaluated, tne APT is uniocsed and control is 
returned to tne caller. It is noted that it is not necessary 
to invoke TC_GETWORK before exiting ADVANCE. If tne current 
VP requires rescheduling, it will have received a virtual 
preempt interrupt from the preemption algorithm. If this has 
occurred, the VP will be rescheduled wnen its running 
process attempts to leave tne Kernel domain and tne virtual 
preempt interrupts are unmasJced. 
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4 


Virtual Preempt Handler 


VIRTUAL_PREEMPT_HANDLER is tne interrupt Handler for 
virtual preempt interrupts. The entry address of 
VIRTUAL_PREEMPT_HANDLER is maintained in the virtual 
interrupt vector located in the Inner Traffic Controller. 
Once invoked, the handler locks the Active Process Table and 
determines which virtual processor is beinfi- preempted by 
calling RUNNING_VP. The process running on tne preempted VP 
is then set to the "ready” state and TC_GETWORE is invoked 
to reschedule tne virtual processor. When TC_GETWORK returns 
to VIRTUAL_PREEMPT_RANDLER, the APT is unlocked and a 
virtual Interrupt return is executed. This return is simply 
a jump to the point in the hardware preempt handler where 
the virtual interrupts are unmasked. This effects a virtual 
interrupt return instruction. 

5. Remaining Procedures 

The remaining two procedures in tne Traffic 
Controller module represent the extended instructions: 
PROCESS_CLASS and GET_DBR_NUMBER. Both procedures lock the 
Active Process Table and call RUNN1NG_VP to determine which 
virtual processor is executing the current process. The 
process ID (viz., APT entry Number) is then extracted from 
the running list. PROCESS_CLASS reads and returns the 
current process' security access classification from the 
APT. GET_DBR_NUMBER reads and returns tne current process' 
DBR handle. It should be noted that in general the DER 
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number provided by procedure GET_DBR_NUMBEH is only valid 
while the APT is locked. Particularly, in the current SASS 
implementation, the Segment Manager invokes GET_DBE_NUMSER 
and then passes the obtained DBF. number to the Distributed 
Memory Manager for utilization at that level. In a more 
general situation, the process associated with the DBR 
number may nave been unloaded before the DBR number was 
utilized, thus making it invalid. This problem does not 
arise in SASS as all processes remain loaded for tne life of 
the system. 

C. DISTRIBUTED MEMORY MANAGER MODULE 

The Distributed Memory Manager module provides an 
interface between the Segment Manager and the Memory Manager 
process, manipulates event data in tne Global Active Segment 
Table (G_AST), and dynamically allocates available memory. A 
detailed description of tne Distributed Memory Manager 
interface to the Memory Manager process was presented by 
Wells [6]. The remaining extended instruction set is 
discussed in detail below. The complete PLZ/ASM source 
listings for the Distributed Memory Manager module is 
provided in Appendix C. 

1. MM Read Eventcount 

MM_READ_E7ENTC0UNT is invoked by the Event Manager 
and tne Traffic Controller to obtain tne current value of 
the eventcount associated with a particular event. The input 
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parameters to tnis procedure are 
and an instance (event Numbe 
identifyparticular event. 

The (x_AST is locJred and 
segment into the G_AST is o 
handle. The instance paramete 
determine which eventcount is 
instance is specified, control i 
specifying an error condition, 
of the specified eventcount is 
unlocked, and the current eve 
the caller. 

2. MM Advance 

MM_AI)VANCE is invoked by 
reflect the occurrence of some 
to MM_ADVANCE are a pointer to 
particular instance (event numbe 
The Global Active Se,emen 
a race condition, and the offset 
the G_AST is obtained from the 
parameter is then validated to d 
to be advanced. If an invalid 
error condition is returned 
entries are affected. If the ins 
appropriate eventcount is incre 
returned. 


a segment handle pointer 
r), which together uniquely 

the entry offset of tne 
btained from the segment's 
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3. MH Ticfcet 


MM_TICKET is Invoicea ty tHe Event Manager to obtain 
tne current value of the sequencer associated witn a 
specified segment. Tne input parameter to MM_TICKET is a 
pointer to a segment's handle. 

Initially, MM_TICKET iocts tne Global Active Segment 
Table to prevent a race condition. Next the offset of the 
segment's entry into the G_AST is obtained from tne segment 
handle. The current value of the sequencer for the specified 
segment is then read and saved as a return parameter to the 
caller. The sequencer value is then incremented in 
anticipation of tne next ticlcet request. Once this is 
complete, the G_AST is unloclced and control is returned to 
the caller. 

-• MM Allocate 

The MM_ALLOCATE procedure provided in this 
implementation is a stub of tne MM_ALLOCa.TE described in tne 
Memory Manager design of Moore and Gary l4j . 

The primary function of MM_ALLOCATE is tne dynamic 
allocation of fixed size biocts of available memory space. 
It is invotea in tne current implementation by tne 
initialization routines in B00TSTiiAP_L0A0ER and TC_INIT for 
the allocation of memory space used in tne creation of tne 
Kernel domain and Supervisor domain staci segments and the 
creation of the Known Segment Tables for user processes. 
Dynamic reallocation of previously used memory space (viz., 
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gavba.ge collection) is not proviiea by tne MM_AILOCATS stub 
in tnis implementation. All memory allocation required in 
tnis implementation is for segments supporting system 
processes tbat remain active, and tnus allocated, for tne 
entire life of tne system. Memory is allocated in biocits of 
256 (decimal) bytes of processor local memory (on-board 
RAM). In tnis stub allocatable memory is declared at compile 
time by a data structure (MZM_POOL) tbat is accessible only 
by MM_ALLOCATE. 


The input parameter to MM_AILOCATE is the number of 
blocJcs of requested memory. Tnis parameter is converted from 
a bloclt size to the actual number of bytes requested. This 
computation is made simple since memory is allocated in 
powers of two. The byte size is obtained by logically 
shiftlns left the input parameter ei^bt times, where eight 
is the power of two desired (viz., 256). Once tne size of 
the requested memory is computed, it is necessary to 
determine tne starting address of tne memory biocK:(s) to be 
allocated. To assist in this computation, a variable 
(NEXT_BLOCK) is used to fceep tracic of tne next available 
bloci of memory in MEM_POOL. NEXT_BLOCK, which is 
initialized as zero, provides tne offset into tne memory 
being allocated. Once the starting address is obtained, the 
physical size of tne memory allocated is added to NEXT_BICCS 
so that the next request for memory allocation will begin at 
the next free byte of memory in MEy_POOL. This new value of 
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NEXT_BLOCK is saved and tne starling address of me memory 
for tnis request is returned to tne caiier. 


D. GATB KEEPER MODULES 


The 

SASS 

Gate Keeper provides 

the 

logi 

cal boundary 

between 

tne 

Supervisor and tne 

Kernel 

and 

isolates tne 

Kernel from 

the system users, thus 

maAine- 

i t 

tamperproof . 

Tnis is 

accomplished by means of tne nardw 

are 

system/normal 

mode and 

the 

software rine-crossin? 

mechanism 

provided by 


tne Gate Keeper. Tne Gate Keeper is comprised of two 
separate modules: l) tne USER_GATE module, and 2) tne 
KERNEL_GATE_KEEPER module. Tnese modules are disjoint, witn 
the USER_GATE module residing in the Supervisor domain and 
tne KERNEL_GATE_KEEPER module residing in tne Kernel domain. 
It is important to note tnat the USER_GATE is a separately 
linked component in tne Supervisor domain and is not liniied 
to the Kernel. The only tning in common between tnese two 
modules is a set of constants identifying tne valid extended 
instruction set which tne Kernel provides to tne users. 

The Gate Keeper modules presented in tnis implenemtation 
are only stubs as they do not provide all of the functions 
required of the Gate Keeper. Rowever, the only tasA not 
provided in this implementation is the validation of 
parameters passed from the Supervisor to the Kernel. A 
detailed description of this parameter validation design is 
provided by Coleman [3] . In the process management 
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demonstration, tne Supervisor stuns are written in PLZ/ASM 
witn all parameters passed by CPU registers. A detailed 
description of the Gate Keeper modules and the nature cf 
their interfaces is presented below. The PLZ/ASM source 
listings for the two Gate Keeper modules are provided in 
Appendix B. 

1. User Gate Module 

The USER_GAT^: module provides the interface 
structure between tne user processes in tne Supervisor 
domain and the Kernel. The USER_GATE is comprised of ten 
procedures (viz., entry points) tnat correlate on a one to 
one basis with the ten ’’user visible" extended instructions 
(listed in figure 6) provided by the Kernel. The only action 
performed by each of these procedures is the execution of 
the "system call" instruction (SC) with a constant value. 
Identifying the particular extended instruction invoJred, as 
the source operand. 

The SC instruction is a system trap tnat forces tne 
hardware into the system mode (Kernel domain) and loads 
register 15 with the system stacx pointer (Kernel domain 
staclc). The current instruction counter value (IC) is pushed 
onto the Kernel stacJc along with tne current CPU flag 
control word (PCW). In addition, the system trap instruction 


is pushed 

onto 

tne 

Kernel staclr witn tne upper 

byte 

representing 

the 

SC 

instruction and the lower 

byte 

representing 

tne 

SC i 

nstruction's source operand (viz. 

, tne 
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Kernel extended instruction code). Togetner, tr.ese 
operations form an interrupt return (IRET> frame as 
illustrated in figure 9. Once tnis is complete, tne ECW is 
loaded witn tne FCW value found in tne System Call frame of 
the Program Status Area (viz., tne hardware "interrupt 
vector"). Tne structure of tne Program Status Area is 
illustrated in figure 12 , Tne instruction counter is then 
loaded witn the address of the SC instruction trap nandler. 
This value is also located in the SC frame of the Program 
Status Area. 

2. Kernel Gate Keeper Module 

The system trap nandler for the System Call 
instruction is the KERNEI_GATE_KEEPER. The address of the 
KERNEL_GATE_KEEPER and the Kernel FCW value are placed in 
the System Call frame of tne Program Status Area hy the 
BOOTSTRAP_LOADER module during initialization. The 
KERNEL_GATE_KEEPER fetches the extended instruction code 
from the trap instruction entry in the IHET frame on the 
Kernel stack. This value is then decoded hy a "case” 
statement to determine which exiendeli instruction is to be 
executed. If the extended instruction cod^ is valid, the 
appropriate Kernel procedure is invoked. Otherwise, an error 
condition is set and no Kernel procedures are not invoked. 
Once control returns to tne KERNEI_GAT'E_KEEPER, the CPU 
registers and normal stack pointer (NSP) value are pushed 
onto tne Kernel stack in preparation for return to tne 
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Supervisor domain. It is noted tnat tnis operation would 
normally occur immediately upon entry into tne 
£ERNi)L_GATS_KiiEP]i!R. In tdis implementation, aowever, 
parameter validation is not accomplisded and tne CPU 
registers are used to pass parameters to and from tne Kernel 
only for use by the process manaeement demonstration. In an 
actual SASS environment, all parameters would be passed in a 
separate argument list and tne CPU registers would appear 
exactly tne same upon leaving tne Kernel as tney did upon 
entering tne Kernel. This is important to insure that no 
data or information is leaked from the Kernel by means of 
the CPU registers. 

Control is returned to tne Supervisor by means of tne 
return mechanism in the hardware preempt hanaler. This 
mechanism is utilized to preclude tne necessity of building 
a Separate mechanism for the KERNEI_GATS_KEEPER that would 
actually perform tne very same function. To accomplish tnis, 
the KBRNEL_GATE_KEEPER executes an unconditional jump to the 
PREEMPT_RET label in PHYS_PREEMPT_HANDLER. This "jump" to 
the hardware preempt handler represents a "virtual IRET" 
instruction providing tne same function as tne virtual 
interrupt return described in the discussion of tne virtual 
preempt handler. At tnis point, tne virtual preempt 
interrupts are unmasked, tne normal stack pointer and CPU 
registers are restored from tne stack, and control is 
returned to the Supervisor by execution of the IRET 
instruction. 
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E. SUMMARY 


Tne implerrenta tior* of process rranaseme 
tne SASS nas teen presented in t 
implementation was discussed in terms of t 
Traffic Controller, Distrituted Memory 
Keeper modules. 

Cnapter 7 will present tne conclusions 
worn and suggestions for future worn 


nt functions for 
nis cnapter. Tne 
he Event Manager. 
Manager, and Gate 

drawn from tnis 
derived from tnis 


thesis . 
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V. CONCias TON 


The implementation of process management for the 
security Kernel of a secure arcnival storage system nas teen 
presented. The process management functions presented 
provide a logical and efficient means of process creation, 
control, and scheduling. In addition, a simple but effective 
mecnanism for inter-process communication, based on tne 
eventcount and setiuencer primitives, was created. Work was 
also completed in tne area of Kernel database initialization 
and a Gate Keeper stub to allow for dual domain operation. 

Tne design for tnis implementation was based on tne 
Zilog Z8001 sixteen bit segmented microprocessor [l7J used 
in conjunction witn tne Zilog 28010 f^emory (management Unit 
[18]. The actual implementation of process management for 
tne SASS was conducted on the Advanced (micro Computers 
Am98/4116 fionoBoard Computer [19] featuring tne AmZS002 
sixteen bit non-seemented microprocessor. Ses-men tat ion 
nardware was simulated by a software (Memory Management Unit 
Imase. 

Tnis implementation was effected specifically to support 
the Secure Archival Storage System (SASS) [21]. However, tne 
implementation is based on a family of Operating Systems [ij 
designed with a primary goal of providing multilevel 
information security. Tne loop free modular design utilized 
in this implementation easily facilitates any required 
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expansion or modification for otner family memcers. In 
addition, tnis implementation fully supports a 
multiprocessor design. Wnile tne process management 
implementation appears to perform correctly, it nas not been 
subjected to a formal test plan. Sncn a test plan snould be 
developed and implemented before Kernel verification is 
begun. 

A. FOLLOW ON WORK 

Tnere are several possible areas in tne SASS aesign tnat 
would be immediately suitable for continued research. In tne 
area of Hardware, tnis includes, tne establishment of a 
multiprocessor environment, hardware initialization, and 
interfacing to tne host computers and secondary storage. 
Further worK in tne Kernel includes tne actual 
implementation of the mem.ory manager process, and the 
refinement of tne Gate Keeper and Kernel intialization 
structures. The implementation of tne Supervisor has not 
been addressed to date. Its areas of research include the 
implementation of the File Manager and Input/Cutput 
processes, and tne final design and implementation of tne 
SASS-Hosts protocols. 

Otner areas tnat could also prove interesting in 
relation to tne SASS include tne implementation of dynamic 
memory management, tne support of multilevel nosts, dynamic 
process creation and deletion, and the provision of 
constructive wortt to be performed by tne Idle process. 

















































APPENDIX A 


EVENT MANAGER LISTINGS 


Za0fe)0ASM 2.0ii 

LOG OBJ CODE STMT SOURCE STATEMENT 
UISTON ?TTT 
EVENT MGR MODULE 


CONSTANT 

TRUE := 1 

FALSE := 0 

READ_ACCESS := 1 

WRITE_ACCESS := 0 

SUCCEEDED := 2 

SEGMENT_NOT_KNOWN := 28 

ACCESS_CLASS_NOT_EO := 33 

ACCESS_CLASS_NOT_GE := 41 

KST_SEG_NO := 2 

NR_0F_KSEGS := 10 

MAX_NO KST ENTRIES := 54 

NOT KNOWN ■ := %FF 


T'^PE 

H_ARRAY ARRAY[3 WORDj 

KST_REC RECORD 
[MM_HANDLE H_ARRAY 

SIZE WORD 

ACCESS_MODE BYTE 

IN_CORE BYTE 

CLASS LONG 

M_SEG_NO SHORT_INTEGER 
ENTRY_NUMBSR SHORT_INTEGER 

J 

EXTERNAL 

MM_TICKET PROCEDURE 

^-'M READ_EVSNTCOUNT PROCEDURE 

tc“advanc£ procedure 

TC_AWAIT PROCEDURE 

PROCESS CLASS PROCEDURE 
CLASS_E5 PROCEDURE 

CLASS_GE PROCEDURE 

ITC GET SEG PTR PROCEDURE 
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INTERNAL 

SSECTION Er_fCST_DCL 

! NOTE: THIS SECTION IS AN "OVERLAY" 

OR "FRAI^E" used TO DEFINE THE 
FORMAT OF THE KST. NO STORAGE IS 
ASSIGNED RUT RATHER THE KST IS 
STORED IN A SEPARATELY OHTAINED 
area, (a segment SET ASIDE FOR IT)! 

$ABS 0 

0000 KST ARRAY[MAX_N0_KST_ENTP1ES KST_RECJ 
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GLOBAL 

SSECTION m GLB PP.OC 


0000 


H£‘AD PROCEDURE 

READS SPECIFIED fiVENTCOUNT 
^ AND RETURNS IT'S VALUE TO - 
THE CALLER 

sic j^s;: :(t V jp WSJC Si« J? Sje jp s?:(t :st jje Jii: ^ Si! :5e SJS 


PARAMETERS: - 

Rl; SEGMENT # 

’i' R2; INSTANCE - 

5^ »,S 5,5 #ic j;; SJS 5^5 


’i' RETURNS: =*« 

R0: SUCCESS CODE 
RR4: fiVENTCOUNT - 


73?3?3(c3?sg!:ics;csg!sic:^:(es;!sj!s;!3;e;t!;;c3(csic;(ts;ts;cs;:si!:t!s;ts;c3^sis I 


ENTR"^ 

! SAVE INSTANCE ! 
0000 93FH PUSH 0R15, R2 


0002 2102 
0004 0001 

0006 5F00 
0008 0000' 


000A 0B00 
000C 0002 

000E 5E0E 
0010 001C' 

0012 97F2 
0014 5F00 
0016 0000’!' 


0018 5E08 
001A 001E' 
001C 97F2 

001E 9E08 
0020 


! "read" ACCESS REQUIRED ! 

LD R2, #READ_ACCESS 

! GET SEG HANDLE & VERIFY ACCESS ! 

CALL CONVERT_AND_VERIFT !R1:SEG # 

R2:RE0. ACCESS 
RETURNS: 
R0:SUCCESS CODE 
Rl .-HANDLE PTR ! 

CP R0, #SUCCEEDED 

IF EQ lACCESS PERMITTED! 

THEN [READ EVENTCOUNT! 

IRESTORE INSTANCE! 

POP R2, PR15 

CALI MM_READ_EVENTCOUNT !R1:HPTP. 

R2:INSTANCE 
RETURNS: 
R0:SUCCESS CODE 
RR4:EVENTC0UNT! 

ELSE !RESTORE SP! 

POP R2, OR15 
FI 
RET 

END READ 
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TICKET PROCEBURS 

'- RETURNS CURRENT VALUE OF - 
’^‘ TICKET TO CALLER AND INCRE- =>« 
^^ENTS SEOUENCER FOR NEXT - 

- TICKET OPERATION 

V ^ ^ ^ ^ 3gc age 3^ ;qc d;c ^ :gc 9gc 2 ^ :;c3;c:;c 9^ sgc :;c 9^ 39 c :gc 

PARAMETERS; 

Ri: SEGMENT # 

a^a^ ajc ajeage agcagcagcagcagcagcagcsgcaicagc age age a^ age age age age age age age age age age age age age 

RETURNS: 

- R0; SUCCESS CODE - 

’t' RR4: TICKET VALUE 

:;c9;c9;c3;t:ec9ic3p3ic9^9;i9;caic^sic3ic3ic3i(;:ic9pjic9:{:ai:9;c};c9^3;:9;«:p^;^ I 


0020 2102 
0022 0000 
0024 5F00 
002b 0000' 


0026 0R00 
002A 0002 

002 c 5E0E 
002E 0038' 
0030 5F00 
0032 0000=^ 


0034 2100 
0036 0002 

0038 9E08 
003A 


ENTRI 

! GET SEG HANDLE & VERIFI ACCESS ! 

! "write" access required ! 

LD R2, ??WRITE_ACCESS 

CALL CONVERT_AND_VERIFY !R1:SEG # 

R2:ACCESS REQ 
RETURNS : 
R0:SUCCESS CODE 
Rl .-HANDLE PTR! 

CP R0, ^SUCCEEDED 

IF EO lACCESS PERMITTED! 

THEN ! GET TICKET ! 


CALL MM_?ICKET IRlrEANDLE PTR 

RETURNS : 
RR4:TICKET! 

! RSTORE SUCCESS CODE ! 

LD R0, ^SUCCEEDED 


FI 

RET 

END TICKET 
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003A 


await PROCjBDURE 


^ CURRENT EVENTCOUNT VALUE IS 
^ COMPARED TO USER SPECIEIED - 
^ VALUE. IF USER VALUE IS =!' 


GREATER THAN CURRENT EVENT- 

- COUNT VALUE THEN PROCESS IS - 
’i' "HLOCKED" UNTIL THE DESIRED 

- EVENT OCCURS . 


ifi ^ SJ* 3i£3i« 3|C 3^ 3^ 3^ ^C3|C 3J* 3^ 3y* SJC 3^ 3|^ 3l(* 3^ 3j|S 3|* 3^3^ Xfi 3,% 


=" PARAMETERS: ^ 

R1 : SEGMENT # ^ 

- R2: INSTANCE (EVENT #) - 

=5“ RR4; SPECIFIED VALUE 

^ 3ic ^ 3)c sgc :tc3^ 9^ V V 7 >r ?7 7 ^ 39 c V 


- RETURNS: 

Re: SUCCESS CODE ^ 


e03A 91F4 

ee3C 93F2 

e03E 2102 
0040 0001 

0042 5F00 
0044 0000' 


0046 0B00 
0048 0002 

004A 5E0E 
004C 005A' 

004E 97F2 

0050 95F4 
0052 5F00 
0054 0000*^ 


ENTRY 

! SAVE DESIRED EVENTCOUNT VALUE ! 

PUSHL 0P.15, RR4 
! SAVE INSTANCE ! 

PUSH 0R15, R2 
! "read" access REOUIRED ! 

LD R2, #READ_ACCESS 

! GET SSG HANDLE ^ VERIFY ACCESS ! 

Call convert_and_verift !ri:seg # 

R2:ACCESS REQ 
RETURNS: 
R0:SUCCESS CODE 
Rl:HANELE PTR! 

CP R0, #SUCCEEDED 

IF EO ! ACCESS PERMITTED ! 

TEEN ! AWAIT EVENT OCCURRENCE ! 

! RESTORE INSTANCE ! 

POP R2, PR15 

! RESTORE SPECIFIED VALUE ! 

POPL RR4, grid 

CALL TC_AWAIT !R1:HANDLE PTR 

R2:INSTANCE 
RR4:VALUE 
RETURNS: 

R0:SUCCESS CODE! 
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0056 

0058 

5E08 
005E ' 

ELSE !RESTORE STACK 

005A 

95F4 

POPI ?.R4, 0R15 

005C 

97E2 

POP R2, GR15 

FI 

005E 

0060 

9E08 

RET 

END AWAIT 
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0060 AD'^ANCi; PP.OCEDURE 

f ^ V V V V ^ V V ^ ^ ^ V V W V ^ ••• ^ ^ V 

V SIGNALS THE OCCURRENCE OF 

- SOME EVENT. EVENTCOUNT IS 

- INCREMENTED AND THE TRAFFIC 

- CONTROLLER IS INVOKED TO 
AWAKEN ANT PROCESS AWAITING 

- THE OCCURRENCE. - 

^ iic 3;c^ 9;c ;ge ^ 9;c 9(C 2 iC ^ 3;$ ^ 9;c 3iS 3;c 3;c ^ 3^ )ic :ijC 

PARAMETERS: =** 

- Rl: SEGMENT # 

R2: INSTANCE (EVENT P) ^ 

^ RETURNS: - 

R0: SUCCESS CODE 


ENTRY 

! SAVE INSTANCE ! 
0060 93F2 PUSH 0R15, R2 


! GET SEG HANDLE & VERIFY ACCESS ! 

! "write" ACCESS REQUIRED ! 

0062 2102 LD R2, #WRITE_ACCESS 
0064 0000 

0066 6F00 CALL CONVERT AND_VERIFY !R1:SEG # 

0068 0000' 

R2:ACCESS REC 
RETURNS: 
R0:SUCCESS CODE 
Rl: HANDLE PTR! 


006A 

006C 

0B00 

0002 

CP R0, ^SUCCEEDED 

IF EO ! ACCESS PERMITTED ! 

006E 

0070 

5E0E 

007C' 

THEN ! advanced EVENTCOUNT ! 

! RESTORE INSTANCE ! 

0072 

97F2 

POP R2, ORlb 

0074 

5F00 

CALL TC_ADVANCE !R1:HANDLE PTR 

0076 

0000’i' 

R2:INSTANCE 
RETURNS : 

R0:SUCCESS CODE! 

0078 

007A 

5E08 

007B' 

ELSE IRESTORE STACK! 

007C 

97F2 

POP R2, 0R15 

FI 

007E 

0080 

9E08 

RET 

END ADVANCE 
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INTERNAL 

SSECTION EM INT PROC 


0(^00 CCNVERT_ANr_7SRIPY PROCEEURE 

f V ^ ^ V V V V nS ^ ^ ^ W ^ ^ ^ W ^ V ^ 'it V V V 

CONVERTS SEGMENT NUMRER TO 5ST INEEX^ 
AND EXTRACTS SEGMENT'S HANDLE PROM “i* 
KST. IP SUCCESSPUL, THEN ACCESS - 

CLASS OP SUBJECT IS CHECKED AGAINST 
’i' ACCESS CLASS OP OBJECT TO INSURE 

- that access is permitted. - 

J^C 3ic :gc sjc ;gc ap ;gc 3ic 3ic ;gc ;gc 9^:«( 3iC Jic:gc Sic 3ic 9 jgc 3iC ;gc >;( 9^ 9^ 9^ 3ic 3ic 3iC :gc ;gc 7 ;gc 

PARAMETERS: 

=•' Rl: SEGMENT NUMBER 
^ R2: ACCESS REQUESTED 

2ie ^V 2je ?}(3^ ^ a(c>^ ^ siC ^ ?je ^ 3}e 9;s 9ic 3ic 9;c 9? 3ic SQC 3^ ?;c 3}c sgc 9^ sq: 9}e 9ic 3^ 9^ sjc 

- RETURNS: ^ 

’i' R0: SUCCESS CODE 

Rl : HANDLE POINTER 

VWV9?9itWW^>r9?^3iS9^V;;<99C9,:9iC9;C9i::tC9^9it9^9jC9it9i:9^V9P9i:9it:?9?9»:97 I 


0000 93P2 

0002 5F00 
0004 0062' 


0006 0B00 
0008 0002 

000A 5E0E 
000C 005E' 

000E 91P4 

0010 5P00 
0012 0000 ^ 


0014 95F0 
0016 1414 
0018 97F1 
001A 93F0 


ENTRY 

! SAVE requested ACCESS ! 

PUSH (?R15, R2 
! GET SEGMENT HANDLE ! 

CALL GET_HANDLE !R1:SEG # 

RETURNS: 

R0:SUCCESS CODE 
R4:HANDLE PTR 
R5:CLASS PTR! 

CP R0, #SUCCEEDED 

IF EO ! SEGMENT IS KNOWN ! 

THEN ! VERIFY ACCESS ! 

! SAVE handle & CLASS PTR ! 

PUSHL 0R15, RR4 
! GET SUBJECT'S SAC ! 

CALL PROCESS_CLASS !RETURNS: 

RR2:PR0C CLASS! 

! RETRIEVE SEG CLASS POINTER ! 

POPL RR0, 0R15 
! GET SEGMENT'S CLASS ! 

LDL RR4, ORl 

! RETRIEVE REQUESTED ACCESS ! 

POP PI, 0R15 
! SAVE HANDLE POINTER ! 

PUSH (?R15, R0 
! CHECK ACCESS CLEARANCE ! 


Ill 




















001C 

001E 

0B01 

0000 

CP Rl 

IF EQ ! 

0020 

0022 

5E0E 

0040 ' 

THEN 

0024 

0026 

5F00 

0000V 

CALL 


0028 

0B01 

CP 

002A 

0000 

IF EO 

002C 

5E0E 

THEN 

0e2E 

0038 ' 


0030 

2100 

LD 

0032 

0021 


0034 

5E08 

ELSE 

0036 

003C ' 


0038 

2100 

LD 

003A 

0002 

FI 

003C 

5E08 

ELSE ! 

003E 

0058' 


0040 

5F00 

CALL 

0042 

0000=*' 



, #WRITS_ACCESS 

WRITE ACCESS REQUESTED ! 

CLASS_EO !RR2;PR0CESS CLASS 

RR4:SEGMENT CLASS 
RETURNS: 

Rl: CONDITION CODE! 

Rl, #FALSE 

lACCESS NOT PERMITTED! 

R0, #ACCESS_CLASS_NOT_EO 
!ACCESS PERMITTED! 

R0, ^^SUCCEEDED 

read access requested ! 

CLASS GE !RR2 .‘PROCESS CLASS 


RR4:SEGMENT CLASS 
RETURNS: 

RlrCONDlTlON CODE! 


0044 

0E01 

CP 

Rl, #EALSE 

0046 

0000 

IF EC 

lACCESS NOT PERMITTED! 

0048 

5E0E 

THEN 


004A 

0054' 



004C 

2100 

LD 

R0, #ACCESS_CLASS_NOT_GE 

004E 

0029 



0050 

5E08 

ELSE 

lACCESS PERMITTED! 

0052 

0058 ' 



0054 

2100 

LD 

R0, #SUCCEEDED 

0056 

0002 

FI 




FI 




! RETRIEVE HANDLE POINTER ! 

0058 

97F1 

POP Rl 

, 0R15 

005A 

5E08 

ELSE 


005C 

0060' 




! RESTORE STACK ! 
005E 97F2 POP R2, 0R15 


FI 

0060 9E08 RET 

0062 END CONVERT AND VERIFY 
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0e62 GET HANDLE PROCEDURE 

CONVERTS SEGMENT NUMBER TO 
KST INDEX AND DETERMINES IF 
’1' SEGMENT IS KNOWN. IF KNOWN >«= 
POINTER TO SEGMENT HANDLE ^ 
AND POINTER TO SEGMENT CLASS’^ 
’i' ARE RETURNED. 

;;c V ^ ^ 99 c ^ M 3;fi ate V ^ ^ ^ age 3^ 3;c 3SC sje 99 c 9gc 39e ^ 

’i' PARAMETERS: 

Rl: SEGMENT NUMBER 


JJt 

RETURNS: 

35 c 


R0: 

SUCCESS CODE 

3? 


R4: 

HANDLE POINTER 

V 


R5: 

CLASS POINTER 

3!C 


tf3f3)t3fWVW^WWW3lfVWWWWWWW J 


ENTRT 

! CONVERT SEGMENT # TO KST INDEX # ! 


0fe}62 

0301 

SUB 

Rl, #NR_0F_KSEGS 


0064 

000A 






! VERIFI KST INDEX ! 


0066 

2100 

LD 

R0, #SUCCEEDED 


0068 

0002 




006A 

0E01 

CP 

Rl, #0 


006C 

0000 

IF LE 

!INDEX NEGATIVE! 


006E 

5E0A 

THEN 



0070 

007A' 




0072 

2100 

LD 

R0, #SEGMENT NOT KNOWN 

0074 

001 c 




0076 

5E08 

ELSE 

!INDEX POSITIVE! 


0078 

0086' 




007A 

0B01 

CP 

Rl, #MAX NO KST ENTRIES 

007C 

0036 

IF 

GT !EXCEEDS MAXIMUM 

INDEX! 

007E 

5E02 

THEN !INVALID INDEX! 


0080 

0086' 




0082 

2100 

LD 

1 R0, #SEGMENT_NOT 

_KNOWN 

0084 

001 c 

FI 





FI 



0086 

0B00 

CP 

R0, #SUCCEEDED 


0088 

0002 

IF EO 

!INDEX VALID! 


008A 

5E0E 

THEN 



008 C 

00BE' 






! SAVE KST INDEX ! 


008E 

93F1 

PUSH 

GR15, Rl 



! GET KST ADDRESS ! 
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1 



0090 

2101 

LD 

Rl, #KST_SEG_NO 

0092 

0002 



0094 

5E00 

CALL 

ITC_G£T_SEG_PTR !fil:KST_SEG_NO 

0096 

0000V 


RETURNS: 
R0:KST ADER! 



r HETPIEVE KST INDEX # ! 

0098 

97F3 

POP 

H3, 0R15 



! CONVERT KST INDEX # TO KST OEFSET 

009A 

1902 

MULT 

RR2, #SIZEOF KST_EEC 

009C 

0010 





! COMPUTE KST ENTRY ADDRESS ! 

009E 

8103 

ADD 

H3, R0 



! SEE 

IF SEGMENT IS KNOWN ! 

00A0 

4D31 

CP 

KST.M_SEG_N0{R3), #NOT_KNOWN 

00A2 

000E 



00A4 

00FF 

IF EO 

ISEGMENT NOT KNOWN! 

00A6 

5E0E 

then 


00A8 

00B2' 



00AA 

2100 

LD 

R0, #SEGMENT_NOT_KNOWN 

00AC 

001C 



00AE 

5E08 

ELSE 

fSEGMENT KNOWN! 

00B0 

00BE' 



00B2 

2100 

LD 

R0, #SUCCEEDED 

00B4 

0002 





! GET HANDLE POINTER ! 

00B6 

7634 

LDA 

R4. KST.MM_HANDLE(R3) 

00B8 

0000 





I GET CLASS POINTER ! 

00BA 

7635 

LDA 

R5, KST.CLASS(R3) 

00BC 

000A 

FI 




FI 


00BE 

9E08 

RET 



00C0 END GET_HANDLE 

END EVENT MGR 
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APPENDIX B - TRAFFIC CONTROLLER LISTINGS 


Z8000ASM ^.02 
LOC OBJ CODE 


STMT SOURCE STATEMENT 


SLISTON $TTY 
TC MODULE 


CONSTANT 


t system PARAMETERS j 


NR PROC 

: = 4 

vp"nr 

:= 2 

nr"cpu 

:= 2 

NR KST 

:= 54 

S'^’STEM CONSTANTS 

RUNNING 

= 0 

READY 

= 1 

BLOCKED 

= 2 

IDLE PROC 

= :5DDDD 

NIL 

= i;ffff 

INVALID 

= %EEEE 

KERNEL STACK 

= 1 

USER STACK 

= 

KST SEG 

= 2 

KST LIMIT 

= 1 

USER FCW 

= :«i80e 

vmiTE 

= 0 




! INDICATES LO'^^EST SYSTEM 
SECURITY CLASS! 


S^STEM_LOW 

STK_OFFSET 

REMOVED 

TRUE 

FALSE 

SUCCEEDED 


0 

:SFF 

%K£CT) 

1 

0 

2 


•pypE 

AP PTR 
VP'PTR 
ADDRESS 
H ARRAY 


WORD 
WORD 
WORD 
ARRAYL3 


WORDJ 
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AP TABLE RECORD 
[NEXT AP 
DBR ■ 

SAC 

PRI 

STATS 

AFPINITY 

VP_ID 

HANDLE 

INSTANCE 

VALUE 

FILi_2 

J 


AP_PTR 

WORD 

LONG 

INTEGER 

INTEGER 

WORD 

7P_PTR 

H ARRAi 

WORD 

LONG 

ARRAY[2 WORDJ 


RUN_ARRAT 
RDY_ARRAI 
AP DATA 
VP~DATA 
INR VP 
FIRST 

J 


ARRAY[VP NR AP_PTRJ 
ARRAY[NR"CPU AP_PTRJ 
ARRAY[NR_PROC AP_TABLIJ 
RECORD 

ARRAY[NR CPU WORDj 
ARRAY[NR^CPU VP_PTRJ 


KST RSC RECORD 

[MM_EANDLE H.ARRAY 


SIZE 

WORD 


ACCESS 

BYTE 


IN CORE 

BYTE 


CLASS 

LONG 


M SEG NO 

SHORT 

INTEGER 

ENTRY NUM 

J 

SHORT, 

INTEGER 

EXTERNAL 



K LOCK 


PROCEDURE 

k“unlock 


PROCEDURE 

SET PREEMPT 


PROCEDURE 

SWAP VDBR 


PROCEDURE 

IDLE 


PROCEDURE 

RUNNING VP 


PROCEDURE 

CREATE TnT 

VEC 

PROCEDURE 

LIST INSERT 


PROCEDURE 

ALLOCATE MMU 

PROCEDURE 

MM ALLOCATE 


PROCEDURE 

UPDATE MMU 

IMAGE 

PROCEDURE 

CREATE STACK 

PROCEDURE 

MM ADVANCE 


PROCEDURE 

MM read EVENTCOUNT 

PROCEDURE 

G AST LOCK 


WORD 

PREEMPT RET 


LABEL 
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e00e 


00A0 

00A2 


0000 


0000 


0000 


$SSCTI0IM TC_DATA 
INTERNAL 

APT RECORD 

r LOCK 

RUNNING_LIST 
READY LIST 
£LOCKiD_LIST 
FILL_3 
7P 

FILL 

AP 

J 


WORD 

RUN_ARRAlf 
RDY ARRAY 
AP_PTR 
LONG 
VP_DATA 
ARRAY [4 WORD) 
AP DATA 


!THESE VARIABLES ARE USED DURING TC 
INITIALIZATION TO SPECIFY AVAILABLE 
ENTRIES IN TEE APT, AND ARE INITIAL¬ 
IZED B"^ TC_INIT IN THIS I t^PLEMEN TAT ION 
NEXT_VP WORD 
APT ENTRY WORD 


SSECTION TC LOCAL 
$ABS 0 

!NOTE: USED AS OVERLAY ONLY! 


ARG_LIST 

[REG 

IC 


RECORD 

ARRAY [i;5 WORDJ 
WORD 


CPU_ID WORD 
SACl LONG 
PR II WORD 


USR_STK WORD 
KER_STK WORD 
KSTl LONG 

J 


$ABS 0 

!NOTE: USED AS STACK FRAME FOR 
STORAGE OF TEMPORARY VARIABLES 
FOR CREATE PROCESS.! 

CREATE “record 
[ARG_PTR WORD 

DBR NUM WORD 

LIMITS WORD 

SEG_ADDR ADDRESS 
N S_P WORD 

J 


sabs 0 

HANDLE_VAL RECORD 
[HIGH LONG 
LOW WORD 

] 
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00043 


0000 


!THE FOLLOWING DECLARATION IS UTILIZED 
AS A STACK FRAME FOR STORAGE OF 
TEMPORARY VA^^IABLES UTILIZED ST 
TC_AD7ANCE AND TC AWAIT.! 

$ASS 0 

TEMP RECORD 


[HANDLE PTR 

WORD 

EVENT NR 

WORD 

EVENT VAL 

LONG 

ID VP" 

WORD 

CPU NUM 

WORD 

HANDLE HIGH 

LONG 

HANDLE LOW 

WORD 


J 

SSECTION TC_KST_DCL 
!NOTE: KST DECLARATION IS USED HERE 
TO SUPPORT KST INITIALIZATION FOR 
THIS DEMONSTRATION ONLY. THIS 
DECLARATION AND INITIALIZATION 
SHOULD EXIST AT THE SEGMENT MANAGER 
LEVEL AND THUS SHOULD BE REMOVED 
UPON IMPLEMENTATION OF SYSTEM 
INITIALIZATION. ! 

$ABS 0 

KST ARRAY[NR_KST KST_RECJ 


118 












































0000 


$SECTION TC INT FROG 

TC_GETyORK " PROCEDURE 

f 3^5iS3iS5|SSJ5SJ|S55535tSit5it5J535SSJ?JJS3|C3JCSJC ^3|«3JC3)C9^3tC3jS 

PROVIDES GENERAL MANAGE- 
- MENT OE USER PROCESSES BY - 
EFFECTING PROCESS SCHEDU- 
^ LING ON VIRTUAL PROCESSORS’^ 


PARAMETERS: 


’i' Rl; CURRENT VP ID 
R3: LOGICAL CPU # 


’i' LOCAL variables: ’i' 

R2: NEXT READY PROCESS 
’i’ R4: AP PTR - 

9;c3ic9ic^^3^^9^a;ea;ca;c3;c9^^^9^3ic:;c3^^a;c:9c^sica;c9^;;c$^a;c I 


0000 6132 
0002 0006' 


0004 0E02 
0006 FFFF 
0008 5E0B 
000A 0010' 
000C 5E08 
000E 0026' 

0010 4E21 
0012 002A' 
0014 0001 
0016 5E0E 
0018 001E' 
001A 5E08 
001C 0026' 


001E 6124 
0020 0020 ' 
0022 A142 
0024 E8EF 
0026 0B02 
0028 FFFF 
002A 5E0E 
002C 003C' 

002E 4D15 
0030 0002' 
0032 DDDD 


ENTR'»’ 

I FIND FIRST READY PROCESS ! 

LD R2, APT.READY_LIST(R31 

GET_REaDT_AP: 

DO IWHILE NOT (END OF LIST OR READY)! 
CP R2, #NIL 

IF EO !NO READY PROCESS! THEN 
EXIT FROM GET_READY_AP 
FI 

C? APT.AP.STATE(R2) , #READY 


IF EO !PROCESS READY! THEN 
EXIT FROM GET_READY_AP 
FI 

! GET NEXT AP FROM LIST ! 

LD R4, APT.AP.NEXT_AP(E2) 

LD R2, R4 

OD 

CP R2,i#NIL 

IF SO ! IF NO PROCESSES READY ! TEEN 

! LOAD IDLE PROCESS ! 

LD AFT.RUNNING_LIST(R1), #IDLE_FROC 
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0034 

0036 

‘iF00 

00005? 

CALL 

IDLE 

0038 

003A 

5E08 

0052' 

ELSE 

! load first READY AP ! 

003C 

003E 

6112 

0002' 

LD 

APT.RUNNING_LIST(R1), R2 

0040 

0042 

0044 

4D25 

002A' 

0000 

LD 

APT.AP.STATE(R2), #RUNNING 

0046 

0048 

6E21 

002B' 

LD 

APT.AP.VP_ID(R2), R1 

004A 

004C 

6121 

0022' 

LD 

Rl, APT.AP.DBR(R2) 

004E 

0050 

5F00 

0000=* 

CALL 

FI 

SWAP_7DBR !(R1:DBR)! 

0052 

9E08 

RET 


0054 


END TC 

GETWORK 
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ee54 

e0b4 

0056 

0058 

005A 

005C 

005E 

0060 

0062 

0064 

0066 

0068 

006A 

006C 

0e6E 

0070 

0072 

0074 

0076 

0078 

007A 

0070 


VIRTUAL_PREEMPT HANDLER PROCEDURE 

- LOADS FIRST READY AP - 
IN RESPONSE TO PREEMPT 
INTERRUPT 


ENTRY 

CALL WAIT_L0CK (APT''.LOCK) 

1=*^ RETURNS WEEN PROCESS HAS LOCKED AFT ! 


7604 

LDA 

R4, APT.LOCK 

0000' 

5F00 

CALL 

K_LOCK 

0000’^ 

! GET 

RUNNING VP ID ! 

5F00 

CALL 

RUNNING_VP IRETURNS: 

0000*^ 




R1 :VF_ID 
R3:CFU a] 


! GET AP ! 

6112 LD R2, APT.RUNNING_LIST(R1) 

0002 ' 

! IF NOT AN IDLE PROCESS, SET IT TO READY ! 
0E02 CP R2, #IDLE_PROC 

DDDD 

5E06 IF NE ! NOT IDLE ! THEN 
0072' 

4D25 ID APT.AP.STATE(R2) , J^READY 

002A' 

0001 

FI 

! LOAD FIRST READY PROCESS ! 

5F00 CALL TC_GSTWORK !R1:VP_IE 

0000 ' 

R3:CPU #! 

!NOTE: THIS IS THE INITIAL POINT OF 
EXECUTION FOP USER PROCESSES.! 
VIRT_PREEMPT_RETURN: 

!=*'=^ CALL UNLOCK (APT''.L0CK) 

returns when PROCESS HAS UNLOCKED APT 
AND ADVANCED ON THIS EVENT 
7604 LDA R4, APT.LOCK 

0000 ' 

5F00 CALL K_UNLOCK 

0000 ^ 
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! PERfORM A VlRTaAL INTERRUPT RETURN 
!NOTE: THIS JUMP EPFECTS A VIRTUAL 
IRET INSTRUCTION.! 

0O7E 5E08 JP PREEMPT_RET 
0080 0000- 

0082 END VIRTUAL PREEMPT HANDLER 
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GLOBAL 

SSECTION TC_GLB_PROC 

0000 TC_INIT PROCEDURE 

^ INITIALIZES APT HEADER 
’i' AND VIRTUAL I NT VECTOR ’i' 

9ic 3;; V aic sjc ^ ^ 3^ s? 3;: ^ 3;c V ^ ^ V V 

PARAMETERS: 

Rl: CPU_ID 
- R2: NR_VP 

3f3f3f3f7f7}C3fSf7;i3f3f3)t!f)f3f3f3f3li3f>)i3}l3f3f3f3f3f3fif3f I 


ENTRY 

! NOTE: THE NEXT FOUR VALUES ARE 
ONLY TO BE INITIALIZED ONCE. ! 


0000 

0002 

0004 

4D05 

00A0' 

0000 

LD 

NEXT_VP, #0 

0006 

0008 

000A 

4D05 

00A2' 

0000 

LD 

APT_ENTRY, <#0 

000 c 

000E 

0010 

4D05 

000A' 

FFFF 

LD 

apt.blocked_list 

0012 

0014 

4D08 

0000' 

CLR 

APT.LOCK 


f :^:^9ic:^9^3^3^3^:gc3gc:gc3ic;gE:;c3r:jc>^:^:p9^3)c:;::?^ 3;:V 

NOTE: THE FOILOWING CODE IS INCLUDED 
ONLY FOR SIMULATION OF A MULTIPROCESSOR 
ENVIRONMENT. THIS IS TO INSURE THAT THE 
READY LIST(S) AND VP DATA 07 THE SIMULATED 
C?U(S) APE PROPERLY INITIALIZED. IN AN 
ACTUAL MULTIPROCESSOR ENVIRONMENT, THIS 
BLOCK OF CODE SHOULD EE RE>'OV£E. 


0016 

2104 

LD R4, ttid 

0018 

0000 

DO 

001A 

0B04 

CP R4, #NR_CPU’^2 

001 c 

0004 

IF EO !ALL LISTS INITIALIZED! 

001E 

5E0E 

THEN EXIT 

0020 

0026' 


0022 

5E08 


0024 

0036' 

FI 
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! INITIALIZE READ! LISTi AS EMPTY ! 


0«26 

4D45 


LD APT.READY_LIST(R4), #NIL 

0028 

0006' 



002A 

FFFF 


! INITIALLY MARK ALL LOGICAL CPU'S 




AS HAVING 1 VP. THIS IS NECESSARY 
TO INSURE TC ADVANCE WILL FUNCTION 
PROPERLY, AS"IT EXPECTS EVERY CPU 
TO HAVE AT LEAST 1 VP. ! 

002C 

4D45 


LD APT.VP.NR_VP(R4) , #1 

002E 

0010' 



0030 

0001 



0032 

A941 


INC R4, #2 

0034 

EeF2 


OD 



! END MULTIPROCESSOR SIMULATION CODE. 




0036 

6F12 

LD 

APT.VP.NR_VP(R1), R2 

0038 

0010' 



003A 

6103 

LD 

R3, NEXT_VP 

003C 

00A0' 



003E 

6F13 

LD 

APT.VP.FIRST(R1), R3 

0040 

0014' 





! RECOMPUTE NEXT VP VALUE FOR TC 



INITIALIZATION OF NEXT LOGICAL 



CPU 

. ! 

0042 

A125 

LD 

R5, R2 

0044 

1904 

MULT 

RR4, #2 

0046 

0002 



0048 

8153 

ADD 

R3, R5 

004A 

6F03 

LD 

NEXT,VP, E3 

004C 

00A0' 





! INITIALIZE RUNNING LIST f 

004E 

6113 

LD 

R3, APT.VP.?IRST(P1) 

0050 

0014' 

DO 


0052 

0E02 

CP 

R2, «0 

0054 

0000 



0056 

5E0E 

IF 

EO then exit FI 

0058 

005E' 



005A 

5E08 



005C 

006A' 



005E 

4B35 

LD 

APT.RUNNING_LIST(R3^. #IDLE_FRCC 

0060 

0002' 



0062 

DDDD 



0064 

A931 

INC 

R3, <*2 

0066 

AB20 

DEC 

R2, #1 

0068 

E8F4 

OD 


006A 

4D15 

LD 

APT.READT_LIST(R1), #NIL 

006C 

0006' 



006E 

FFFF 
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0070 

2101 

0072 

0000 

0074 

7602 

0076 

0054' 

0078 

5F00 

007A 

0000*^* 

007C 

007E 

9E08 


LD R1 , #13 
! SNTRY ADDRESS ! 

LDA m, VIRTUAL_PREE.VPT_HANDLER 

CALL CREATE_INT_VSC 

!R1:VIRTUAL INTERRUPT # 

R2:INTERRUPT HANDLER ADDRESS 

PET 

END TC INIT 
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ee7E 


create process procedure 


- CREATES USER PROCESS '••' 
=!' DATABASES AND APT 
’i' ENTRIES 


S|S SJ6 9^ 9JC 9JC SJS 3|*9^ 5JS 3?5? SjS 9^ JJS 


PARAMETERS : 

’i' Rl4: argument PTR 

37VSrwx:j 


ENTRY 

!N0TE; this PROCEDURE IS A STUB TO ALLOW 
PROCESS INITIALIZATION FOR THIS 
DE^-'ONSTRATION . ! 

! ESTABLISH STACK PRAMS FOR LOCAL 
VARIABLES, ! 


00?E 

030F 

SUB 

R15, #SIZEOF CREATE 

0080 

000A 





! STORE INPUT ARGUMENT POINTER ! 

0082 

6FFE 

LD 

CREATE.ARG^PTR(R15), R14 

0084 

0000 





! LOCK APT ! 

0086 

7604 

LDA 

R4, APT.LOCK 

0088 

0000 ' 



008A 

5F00 

CALL 

K_LOCK 

008C 

oeoe*!* 





! RETURNS WHEN APT IS LOCKED ! 

! CREATE MMU ENTRY FOR PROCESS ! 

008E 

5F00 

CALL 

ALLOCATE_MMU ’RETURNS: 

0090 

0000V 


R0: DBR ff! 



! GET 

NEXT AVAILABLE ENTRY IN APT 

0092 

6101 

LD 

Rl, APT ENTRY 

0094 

00A2' 





! COMPUTE APT OFFSET • 

0096 

2102 

LD 

R2, #SIZEOF AP.TABLE 

0098 

0020 



009A 

8112 

ADD 

R2, Rl 



! SAVE NEXT AVAILABLE APT ENTRY ! 

009C 

6F02 

LD 

APT_ENTRY, R2 

e09E 

00A2' 





! create apt entry for process ! 

00A0 

4D15 

LD 

APT.AP.NEXT_AP(Rl), #NIL 

00A2 

0020' 



00A4 

FFFF 



00A6 

6F10 

LD 

APT.AP.DBR(R1), R0 

00A8 

0022' 

! GET 

PROCESS CLASS ! 

00AA 

54E2 

LDL 

RR2, ARG_LIST.SAC1(R14) 

00AC 

001E 



00AE 

5D12 

LDL 

APT.AP.SAC(R1), RR2 


126 
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m 



00B0 0024' 




! GST 

PROCESS PRIORITY ! 

00B2 

61E2 

LD 

R2, ARG_LIST.PRI1(R14) 

00B4 

0022 



00E6 

6F12 

LD 

APT.AP.PRI(Rl), R2 

00Be 

0028' 

! GET 

LOGICAL CPU # ! 

00BA 

61E2 

LD 

R2, APG_LIST.CPU_ID(R14) 

00EC 

001C 



00BE 

6F12 

LD 

APT.AP.AFFINITY(Rl), R2 

00C0 

002C' 





ITHREAD IN LIST AND MAKE READY! 

00C2 

7623 

LDA 

R3, APT.READY_LIST(P.2) 

00C4 

0006' 



00C6 

7604 

LDA 

R4, APT.AP.NEXT_AP 

00C8 

0020' 



00CA 

7605 

LDA 

R5, APT.AP.PRI 

cecc 

0028' 



00CE 

7606 

LDA 

R6, APT.AP.STATE 

00D0 

002A' 



00D2 

2107 

LD 

R7, #READY 

00D4 

0001 



00D6 

AD 21 

EX 

Rl, R2 



! SAVE DER # ! 

00 D8 

6FF0 

LD 

create.D3R_NUM(R15), R0 

00DA 

0002 



00DC 

5F00 

CALL 

LIST_INSERT 

00DE 

0000>P 






IR2: OBJ ID 




R3: LIST HEAD PTR 

R4: NEXT OBJ PTR 

R5: PRIORITY PTR 

R6: STATE PTR 

R7: STATE! 


! UNLOCK APT ! 


00E0 

7604 

LDA 

R4, APT.LOCK 

00E2 

0000' 



00E4 

5F00 

CALL 

K_UNLOCK 

00E6 

0000’!' 





'CREATE USER STACK! 



! RESTORE ARGUMENT POINTER ! 

00Ee 

61FE 

LD 

R14, CREATE.ARG_PTRfR15) 

00EA 

0000 



00EC 

61E3 

LD 

R3, ARG_LIST.USR_STK(R14) 

0eEE 

0024 





! SAVE LIMITS ! 

00F0 

6FF3 

LD 

CREATE.LIMITS(R15}, R3 

00F2 

0004 
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00F4 

5F00 

CALL 

MM_ALLOCATE !R3: a OF BLOCKS 

00F6 

0000S.S 






RETURNS: 




R2: START ADDR! 



!COMPUTE & SA?E NSP! 

00F8 

A128 

LD 

R8, R2 



! ESTABLISH INITIAL SP VALUE 



FOR 

USER STACK. ! 

00FA 

0108 

ADD 

R8, #STK_OFFSET 

00FC 

00FF 



00FE 

6FF8 

LD 

create.N_S_P(R15), RS 

0100 

0008 





! RESTORE LIMITS ! 

0102 

61F4 

LD 

R4, CREATE.LIMITS(R15) 

0104 

0004 



0106 

AB40 

DEC 

R4 !SEG LIMITS! 



! RESTORE DBR ! 

0108 

61F0 

LD 

R0, create.DBR_NUM(R15) 

010A 

0002 



010C 

2101 

LD 

Rl, #user_stack 

010E 

0003 



0110 

2103 

LD 

R3, #WR1TE !ATTRIBUTE! 

0112 

0000 



0114 

5F00 

CALL 

UPDATE_MMU_IMAGE 

0116 

0000=«‘ 




IH0: DBR n 
Hi: SEGMENT 
R2: SEG ADDRESS 
R3: SEG ATTRIBUTES 
R4: SEG LIMITS! 
'CREATE KERNEL STACK! 

! RESTORE ARGUMENT POINTER ! 


0118 

011A 

61FE 

0000 

LD 

R14., CREATE.ARG_ 

PTR(R16) 

011C 

011E 

61E3 

0026 

LD 

R3, ARG_LIST.KER 

_STK(R14) 

0120 

0122 

5F00 

0000=1' 

call 

MM_ALLOCATS !R3: 

n OF BLOCKS 


RETURNS 

R2: START ADER! 

IMAKE MMU ENTRY! 

! RESTORE DBR n ! 


0124 

0126 

61F0 

0002 

LD 

R0, 

CREATE.DBR_NUM(R15) 

0128 

012A 

2101 

0001 

LD 

Rl, 

#KERNEL_STACK 

012C 

A134 

LD 

R4, 

R3 

012E 

AB40 

DEC 

R4 


0130 

0132 

2103 

0000 

LD 

R3, 

#¥RITE 



! SAVE START ADDRESS ! 


12b 




0134 

6FF2 

LD 

CREATE.SEG_ADDR(R15), R2 

0136 

0006 



0138 

5F00 

CALL 

UPDATE_MMU_IMAGE 

013A 

0000^ 


!Re: DBR a 


iil; SEGMENT # 

R2: SEG ADDRESS 
R3: SEG ATTRIBUTES 
R4: SEG LIMITS! 
lESTABLISH ARGUMENTS! 

! RESTORE ARGUMENT POINTER ! 


013C 

61FE 

LD 

R14, CREATE .ARG_PTR(R15) 

013E 

0000 





! RESTORE STACK ADDRESS ! 

0140 

61F1 

LD 

Rl, create.SEG_ADDR(R l5) 

0142 

0006 



0144 

2103 

LD 

R3, #USER_FCW 

0146 

1800 



0148 

61E4 

LD 

R4, ARG_IIST.IC(R14) 

014A 

001A 





! RESTORE INITIAL NSP ! 

014C 

61F5 

LD 

R5, CREATE.N_S_P(R15) 

014E 

0008 



0150 

7606 

LDA 

R6, VIRT_PREEMPT_RETURN 

0152 

0076' 



0154 

030F 

SUB 

R15, P8 

0156 

0008 



0158 

1CF9 

LDM 

GR15, R3, #4 

015A 

0303 





! LOAD ARGUMENT POINTER FOR 



CREATE STACK CALL ! 

015C 

A1F0 

LD 

R0, R15 

015E 

93F1 

PUSH 

0R15, Rl 

0160 

AlEl 

LD 

Rl, R14 



! LOAD INITIAL REGISTER VALUES 



BE 

PASSED TO USER PROCESS AS 



INITIAL PARAMETERS. ! 

0162 

5C11 

LDM 

R2, ARG_LIST.REG(R1U Pi 

0164 

020C 



0166 

0000 



0168 

97F1 

POP 

Rl, 0R15 

016A 

5F00 

CALL 

CREATE^STACK 

016C 

0000V 






!R0: ARGUMENT PTR 




Rl: TOP OF STACK 


R2-R14: INITIAL 
REG STATES! 


!NOTE: THE ABOVE INITIAL REG STATES 
REPRESENT THE INITIAL PARAMETERS 
(VIZ., REGISTER CONTENTS^ THAT A 
USER PROCESS WILL RECEIVE UPON 
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INITIAL EXECUTION. 


016E 

0170 

010F 

0008 

ADD R16, #8 lOVERLAY PARAMETERS! 

! ALLOCATE KST ! 

0172 

0174 

2103 

0001 

LD 

R3, #KST_LIMLT 

0176 

5F00 

CALL 

MM ALLOCATE IP.3:# OF BLOCKS 

0178 

0000’!' 

RETURNS 

R2:START ADD?.! 

! RESTORE DBR ! 

017A 

017C 

61F0 

0002 

LD 

! SAV 

R0, create.DBR_NUM(R15) 

S KST ADDRESS ! 

017E 

0180 

6FF2 

0006 

LD 

IMAKE 

CREATE.SEG_ADDR(H15K R2 

MMU ENTRY FOR KST SEG! 

0182 

0184 

2101 

0002 

LD 

Rl, #KST_SSG 

0186 

0188 

2103 

0000 

LD 

R3, #WRITE !ATTRIBUTE! 

018A 

018C 

2104 

0000 

LD 

R4, #KST_LIMIT-1 

018E 

0190 

5F00 

0000’5' 

CALL 

UPDATE_MMU_IMAGE 


0192 61F2 
0194 0006 

0196 5F00 
0198 01A0' 


ei9A 010F 
019C 000A 
019E 9E08 
01A0 


!R0: DBR u 
Rl: SEGMENT # 

R2: SEG ADDRESS 
R3: SEG ATTRIBUTES 
R4: SEG LIMITS! 

! RESTORE KST ADDRESS ! 

LD R2. CREATE.SEG_ADDR(R15) 

! CREATE INITIAL KST STUB ! 
CALL CREATE_KST !R2:KST ADDP! 

! REMOVE TEMPORARI VARIABLE 
STACK FRAME. ! 

ADD R15, #SI2EOF CREATE 

RET 

END CREATE PROCESS 
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01A0 CPBATE_KST PROCEDURE 

f 3{« 9^* 3|* 9^* 3 |b 9^* 9|» 9^ SQC iji 9^* ^ ^ 

’i' CREATES KST STUB FOR 
^ PROCESS ^'ANACEMENT =“ 

- DEMO. INSERTS ROOT - 

^ ENTRY IN KST. NOT 
=«' INTENDED TO BE FINAL 
PRODUCT. - 

>ic :;e :jC ^je J(C :(t J)6 V V Sf W ^ V >tS Sit >!» V V 

’i' PARAMETERS: 

R2: KST ADDRESS - 

ENTRY 

'NOTE: THIS PROCEDURE IS A STUB USED 
FOR INITIALIZATION IN THIS IMPLEMENTATION 
ONLY. THE ACTUAL INITIALIZATION CODE 
FOR THE KST WILL RESIDE ^T THE SEGMENT 
MANAGER LEVEL ONCE IMPIEMENTATION OF 
SYSTEM INITIALIZATION IS EFFECTED. ' 


! CREATE ROOT ENTRY IN KST ' 


01A0 

1406 

LDL 

RR6, #-l 'ROOT HANDLE 

01A2 

FFFF 



01A4 

FFFF 



01A6 

5D26 

LDL 

KST.MM_EANDLE(R2), RR6 

01A8 

0000 

!SET 

ROOT ENTRY « IN G AST ! 

01AA 

4D25 

LD 

KST.MM_HANDLE[2JYR2), 

01AC 

0004 



eiAE 

0000 





! SET ROOT CLASSIFICATION ! 

01B0 

1406 

LDL 

RR6, «SYSTEM_LOW 

01JB2 

0000 



01B4 

0000 



01B5 

5D26 

LDL 

KST.CLASS(R2), RR6 

eiBS 

000A 

!SET 

MENTOR SEG #! 

01BA 

4C25 

LDB 

KST.M_SEG_N0(R2), #0 

01BC 

000E 



01BE 

0000 





'INITIALIZE FREE KST ENTRIES 



FOR 

DEMO. NOT FULL KST' 

01C0 

2101 

LD 

Rl, #10 

01C2 

000A 

DO 


01C4 

0B01 

CP 

Rl, #0 

01C5 

0000 



eic8 

5E0E 

IF 

EC THEN EXIT FI 

01CA 

01D0' 



01CC 

5E08 
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01CE 

01D0 

01DE' 

0102 

ADE 

R2, #SIZEOF KST_REC 

01D2 

0010 



01D4 

4C25 

IDE 

KST.M_SEG_NO(R2), #tFF 

01D6 

000E 



01D8 

01DA 

EFFF 

AB10 

DEC 

R1 

01DC 

EHF3 

OD 


01DE 

9E08 

EET 


01E0 


END CR£ATE_5ST 
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TC_AD7ANCE procedure 

=!' B7ENTC0UNT IS ADVANCED BY 

- INVOCATION OF MM ADVANCE. 
PROCESSES THAT aRE AWAITING ^ 
THIS EVENT OCCURRENCE ARE ’i' 

- REMOVED FROM THE BLOCKED LIST- 
AND MADE READY. THE READY - 

’i' LISTS ARE THEN CHECKED TO 
’i* INSURE PROPER SHEDULINC- IS 
^ EFFECTED. IF NECESSARY VIR- 
=«' TUAL PREEMPTS ARE SENT TO ALL*^ 

- THOSE VP'S BOUND TO LOWER - 
=5' PRIORITY PROCESSES. 

^^^ ;qc :ge 9^ sjc V 3?: 3^ ajc :ge 9^ 99e :ge ^ :geV 3gc 


- PARAMETERS: 

Rl: HANDLE POINTER 
=5* R2: INSTANCE (EVENT #) 


sjc V V 39^ 3^ V 3^ 3^ 3;c 91^: Jis 9^ 9,s 3^ s;: 


3? 

3|*3JS 9,9 9|9 9,% 


=!« RETURNS : 

^ R0: SUCCESS CODE ’i' 

9|» SJS 3^3|C 3{* 3^ «{« 3^ 3|C 3^ 39* 3iC3^ 39* 3|^ ifi *i[*39i* 39* 39* 39* 39* V39* S|* S** V f 


01E0 030F 
01E2 0012 

01E4: 6FF1 
01E6 0000 
01E8 6FF2 
eiEA 0002 

01EC 7504 
01EE 0000' 
01F0 5F00 
01F2 0000’i' 


01F4 5F00 
01F6 0000’i‘ 


01F8 0B00 
01FA 0002 
01FC 5E0E 
01FE 0372' 


ENTRY 

! ESTABLISH TEMPORARY VARIABLE 
STACK FRAME. ! 

SUB R15, #SIZE0F TEMP 

! SAVE INPUT ARGUMENTS ! 

LD TEMP.HANDLE_PTR(R15) , Rl 

LD TEMP.EVENT_NR(R15) , R2 

! LOCK APT ! 

LDA R4, APT.LOCK 

CALL K_LOCK 

! RETURNS WHEN APT IS LOCKED ! 

! ANNOUNCE EVENT OCCURRENCE BY 
INCREMENTING SVEnTCOUNT IN G AST 
CALL MM_ADVANCE !R1-.HANDLE PTR 

R2:INSTANCE 
RETURNS: 
R0:SUCCESS CODE 
RR2:BVENTC0UNT! 
CP R0, #SUCCEEDED 

IF EO THEN 
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! SAVE EVENTCOUNT ! 


0200 

5DF2 

LDL 

TEMP.EVENT_VAL(R15), RR2 

0202 

0004 





! RESTORE INSTANCE ! 

0204 

6ir0 

LD 

R0, T£MP.EVENT_NR(Rlb) 

0206 

0002 





! RESTORE HANDLE POINTER ! 

0208 

61F1 

LD 

Rl, TE^!P.HANDLE_PTH (Rib) 

020A 

0000 





! SAVE HANDLE ! 

020C 

5414 

LDL 

RR4, HANDLE_VAL.EIGH(R1) 

020E 

0000 



0210 

5DF4 

LDL 

TSMP.HANDLE_flIGH(R15), RR4 

0212 

000C 



0214 

6114 

LD 

P4, HANDLE_VAL.L0W(R1) 

0216 

0004 



0218 

6FF4 

LD 

TEMP.FANDLE_L0W(R15), R4 

021A 

0010 




! AWAKEN ALL PROCESSES AWAITING 
THIS EVENT OCCURRENCE ! 

! GET FIRST BLOCKED PROCESS ! 


021C 

6101 

LD 

Rl, APT.BLOCKED_LIST 

021E 

000A ' 



0220 

7606 

LDA 

R6, APT.BLOCKED_LIST 

0222 

OO0A' 

WAKE UP 

• 

• 



DO 




! DETERMINE IF AT END OF BLOCKED LIS 

0224 

0B01 

CP 

Rl, #NIL 

0226 

FFFF 

IF EC 

! NO MORE BLOCKED PROCESSES ! 

0228 

5E0E 

TEEN 

EXIT FROM WAKE_UP 

022A 

0230' 



0220 

5Eoe 



022E 

02B4' 

1—1 




! SAVE NEXT ITEM IN LIST ! 

0230 

6117 

LD 

R7, APT.AP.NEXT_AP(R1) 

0232 

0020' 





! DETERMINE IF PROCESS IS ASSOCIATED 



WITH CURRENT HANDLE ! 

0234 

54F4 

LDL 

RR4, TEMP.HANDLE_HIGH(R15) 

0236 

0oec 



0238 

5014 

CPL 

RR4, APT.AP.HANDIE(R1) 

023A 

0030' 

IF EC 

!HIGH HANDLE VALUE MATCHES! 

023C 

5E0E 

TEEN 


023E 

02A2' 



0240 

61F4 

LD 

R4, TEMP.HANDLE_I0W(R15) 

0242 

0010 



0244 

4B14 

CP 

R4, APT.AP .HANDLE[2J (Rl) 
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0246 

0034' 





IF Eg ! HANDLE S MATCH ! 

0248 

5E0E 

THEN ! CHECK FOR INSTANCE MATCH ! 

024A 

029C' 



024C 

61F0 

LD R0 

, TEMP.EVSNT_NR(R15) 

024E 

0002 



0250 

4E10 

CP R0 

, APT.AP.INSTANCE(R1) 

0252 

0036 ' 





IF EC ! 

INSTANCE MATCHES ! 

0254 

5E0E 

THEN 'DETERMINE IF THIS IS THE 

0256 

0296' 





OCCURRENCE THE PROCESS 



WAITING FOR ! 

0258 

54F2 

LDL 

RR2, TEMP.EVENT_VAL(R15) 

025A 

0004 



025C 

5012 

CPL 

RR2, APT.AP.VALUE(R1) 

025E 

0038' 





IF GE 

lAWAITED EVENT HAS OCCUHRED 

0260 

5E01 

THEN 

! AWAKEN PROCESS ! 

0262 

0290' 





! REMOVE FROM BLOCKED LIST ! 

0264 

2F67 

LD 

0R6, R7 



! SAVE local VARIABLES ! 

0266 

91F6 

PUSHL 0R15, RR6 



!SET 

LIST threading ARGUMENTS! 

0268 

6112 

LD 

R2, APT.AP.AFFINITY(RI) 

026A 

002C ' 



026C 

7623 

LDA 

R3, APT.READY_LIST(R2) 

026E 

0006' 



0270 

7604 

LDA 

R4, APT.AP.NEXT_AP 

0272 

0020' 



0274 

7605 

LDA 

P5, APT.AP.PRI 

0276 

0028' 



0278 

7606 

LDA 

R6, APT.AP.STATE 

027A 

002A' 



027C 

2107 

LD 

R7, #READr 

027E 

0001 



0280 

A112 

LD 

R2, R1 

0282 

5F00 

CALL 

LIST_INSERT 

0284 

0000=5' 





!R2 

: OBJ ID 



R3 

: LIST HEAD PTR 



R4 

: NEXT OB: PTR 



R5 

: PRIORITY PTR 



R6 

: STATE PTH 



R7 

; STATE VALUE ! 



! RESTORE LOCAL VARIABLES ! 

0286 

95F6 

POPL 

fiR6, GRlb 

0288 

2103 

LD 

Rll, #REMOVED 

028A 

ABCD 




028C 5E0S 


ELSE IPROCESS STILL BLOCKED! 
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e2SE 

0290 

0292' 

8 DBS 

CLR Rll 

0292 

5E08 

FI ! END VALUE CHECK ! 

ELSE '.PROCESS STILL BLOCKED! 

0294 

0296 

0298' 

8DB8 

CLR Rll 

0293 

5E08 

FI ! END INSTANCE CHECK ! 

ELSE fPROCESS STILL BLOCKED! 

029A 
029 C 

029E' 

SDBS 

CLR Rll 

029E 

5E0e 

FI ! END HANDLE CHECK ! 

ELSE 'PROCESS STILL BLOCKED! 

02A0 

02A2 

02A4 ' 
SDBS 

CLR Rll 

02A4 

0B0B 

FI ! END HIGH HANDLE CHECK ! 

! RESET AP POINTER REGISTERS ! 

CP Rll, #REMOVED 

02A6 

02A8 

AECD 

5E06 

IF NE f PROCESS IS STILL BLOCKED ! 
THEN 

02AA 

02AC 

02B0' 

7616 

LDA R6, APT.AP.NEXT_AP(R1) 

02AE 

0020' 


02B0 

A171 

FI 

LD Rl, R7 

02B2 

E8B8 

OD 

02B4 

3D28 

! DETERMINE IF ANY VIRTUAL PREEMPT 
INTERRUPTS ARE REQUIRED ! 

CLR R2 

02B6 

0B02 

PREEMPT CHECK: 

DO 

CP R2, #NR_CPU 2 

02B8 

02BA 

0004 

5E0E 

IF EC !aLL ready LISTS CHECKED! THEN 

02BC 

02BE 

02C2' 

5E08 

EXIT FROM PREEMPT_CHECK 

02C0 

0366' 



FI 

! CREATE PREEMPT VECTOR FOR VP'S ! 


02C2 

8D18 

CLR 

Rl 



DO IFOR Rl=l TO NR VP'S! 

02C4 

A910 

INC 

Rl 

02C6 

4E21 

CP 

Rl, APT.VP.NR_VP(R2) 

02C8 

0010' 





IF GT 

! PREEMPT VECTOR COMPLETED ! 

02CA 

5E02 

THEN 

EXIT 

02CC 

02D2' 



02CE 

5E08 



02D0 

02D8 ' 

FI 


02D2 

0DF9 

PUSH 

0R15, #TRUE 
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02D4 

0001 



02D6 

EfcF6 

OD 

! # TO 

PREEMPT ! 

02D8 

8D38 

OLH 

R3 

02DA 

6124 

LD 

R4, APT.VP.NE_VP(R2) 

02DC 

0010' 

! # OF 

VP'S ! 



! GET 

FIRST READY PROOESS ! 

02DE 

6121 

LD 

Rl, APT.READY LIST(R2) 

02E0 

0006' 





OHEOK HDY LIST: 



DO 




! SEE 

IF READY LIST IS EMPTY ! 

02E2 

0B01 

OP 

Rl, #NIL 

02E4 

FFFF 

IF EO 

!LIST IS EMPTY' 

02E6 

5E0E 

THEN 

EXIT FROM GHEGK_RDY_LIST 

02E8 

02EE' 



02EA 

5E08 



02EC 

0324' 

FI 


02EE 

4D11 

OP 

APT.AP.STATE(R1), ^RUNNING 

02F0 

002A' 



02F2 

0000 

IF EO 

!PROGESS IS RUNNING! 

e2F4 

5E0E 

THEN 

!DON'T PREEMPT IT! 

02F6 

0300 ' 



02F8 

6115 

LD 

R5, APT.AP.VP_ID(R1) 

02FA 

002E' 





!OOMPUTE LOOATION IN PREEMPT VEOTOP 

02FC 

4325 

SUB 

R5, APT.VP.FIRST(R2) 

02FE 

0014' 



0300 

74F6 

LDA 

R6, R15(R5) 

0302 

0500 



0304 

0D65 

LD 

0R6, ffFALSE 

0306 

0000 



0308 

5E08 

ELSE 

! PREEMPT IT ! 

030A 

030E' 



0300 

A930 

INO 

R3 



FI 


030E 

AB40 

DEO 

R4 

0310 

0B04 

OP 

R4, #0 

0312 

0000 

IF EO 

'ALL VP'S VERIFIED! 

0314 

5E0E 

THEN 


0316 

0310' 



0318 

5Ee8 

EXIT FROM OHEOK RDY LIST 

031A 

0324' 

FI 




! GET 

NEXT AP IN READY LIST ! 

0310 

6110 

LD 

Re, APT.AP.NEXT_AP(R 1 ^ 
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031£ 

0020' 


0320 

A101 

LD HI, R0 

0322 

E8DF 

OD !END CHECK RDY LIST! 

! SET NECESSARY PREEMPTS ! 

0324 

6124 

LD R4, APT.VP.NR_VP(R2) 

0326 

0010' 


0328 

6121 

LD Rl, APT.yP.FIHST(R2) 

032A 

0014' 

SEND PREEMPT: 

DO 

032C 

97E0 

POP R0, 0R15 

! CHECK TEMPLATE ! 

032E 

0B00 

CP R0, #TRUE 

0330 

0001 

IF Eg !CAN EE PREEMPTED! 

0332 

5E0E 

THEN 

0334 

0350' 


0336 

eB03 

CP R3, #0 

0338 

0000 

IF GT ! preempts REOUIRED 

033A 

5E02 

THEN !PREEMPT IT! 

033C 

0350' 

!SAVE ARGUMENTS! 

033E 

93F1 

PUSH OR15, R1 

0340 

91F2 

PUSHL GE15, RR2 

0342 

93F4 

PUSH 0R15, R4 

0344 

5Fe0 

CALL S£T_PREEMPT 

0346 

0000>s 

!Pl: VP ID! 

! RESTORE ARGUMENTS ! 

0348 

97F4 

POP R4, GR15 

034A 

95F2 

POPL RR2, GR’15 

034C 

97F1 

POP Rl, GR15 

034E 

AB30 

DEC R3 

FI 

FI 

0350 

A911 

INC Rl, #2 

0352 

AB40 

DEC R4 

0354 

0B04 

CP R^, «0 

0356 

0000 

IF EO ! STACK RESTORED! 

0358 

5E0E 

THEN 

035A 

0360' 


035C 

5E08 

EXIT 

035E 

0362' 

FI 

0360 

SeE5 

OD !END SEND PREEMPT! 

! CHECK NEXT READY LIST ! 

0362 

A921 

INC R2, #2 

0364 

E8A8 

OD !END PREEMPT CHECK! 
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! UNLOCK APT ! 


0366 

7604 

LDA 

R4. APT.LOCK 

0368 

0000' 



036A 

6F00 

CALL 

K_UNLOCK 

036C 

0000’!' 





! RESTOPE SUCCESS CODE 

e36E 

H100 

LD 

R0, #SUCCESDED 

0370 

0002 

FI 




! RESTORE STACK ! 

037^ 

010F 

ADD 

R15, #SIZEOF TEMP 

0374 

0012 



0376 

9E0S 

RET 


0378 


END TC 

advance 
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ti!378 TC AWAIT PROCBDUR 

CHECKS USER SPECIFIED VALUE 

- AGAINST CURRENT EVSNTCOUNT 

=»' VALUE. IF USER VALUE IS LESS - 

- THAN OP equal EVENTCOUNT THEN- 


- CONTROL IS RETURNED TO USER. - 
ELSE USSR IS RLOCKED UNTIL - 
EVENT OCCURRENCE. 

3^*^ »|C 2^ S|%3|C S|&#^C SjS 3^ 2|C3J« #^C 3yS 3iC Sfi ^ V 

’i' PARAMETERS : ’i' 

Rl: HANDLE POINTER 
’p R2 : INSTANCE (EVENT ^ 

RR4: SPECIFIED VALUE - 

V 5? =!« V 5!s J!s :S5 :jt Sit Jit 3(t s)t sjt ^i« V ^ s? Si* >:« V sp W V 

’i' RETURNS : 

- R0; SUCCESS CODE - 

HtVJStJitJStJitJJiJiCSJtJit^tJitSit^t^tJJiJitSiSJltSitSitJitSitSitSpSitSitSitJitSitSitJit f 


ENTRY 


! ESTABLISH STACK FRAME FOR 

temporary variables. ! 


0378 

030F 

SUB 

R15, #SIZEOF TEMP 

037A 

0012 

! SAV 

S INPUT PARAMETERS ! 

037C 

6FF1 

LD 

TEMP.HANDLE_PTR(R15), Rl 

037E 

0000 



0380 

6FF2 

LD 

TEMP.EVENT_NR(R16U R2 

0382 

0002 



0384 

5DF4 

DDL 

TEMP.EVENT_VAL(R15), RR4 

0386 

0004 





! LOCK APT ! 

0388 

7604 

LDA 

R4, APT.LOCK 

038A 

0000' 



03ac 

5F00 

CALL 

K_LOCK 

038B 

0000Sit 





! RETURNS WHEN APT IS LOCKED ! 



! GET 

CURRENT EVENTCOUNT ! 

0390 

5F00 

CALL 

MM_READ_EVENTCOUNT 

0392 

0000=5' 




!Rl:HANDLE POINTER 
R2:INSTANCE 
RETURNS: 

R0;SUCCESS_CODE 
RR4; EVENTCOUNT! 

0394 0B00 CP R0, #SUCCEEDED 
0396 0002 

0398 5E0E IF EQ THEN 
039A 0440' 

! DETERMINE IF REQUESTED EVENT 
HAS OCCURRED ! 


7't 










































05yc 

54F5 

LDL RR6, TEMP.EVENT VAL(R15) 

e39E 

0004 



03A0 

9046 

OPL RRe, RR4 



IF GT 

!EVENT HAS NOT OOOURRED! 

03A2 

5E02 

THEN 

!iLOOK PROOESS! 

03A4 

0440' 





! identify PROOESS ! 

03A6 

5F00 

OALL 

RUNNING_VP ’RETURNS: 

03A8 

0000’!' 






Rl:VP ID 




R3:0PU 



! SAVE RETURN VARIABLES ! 

03AA 

6FF1 

LD 

TEMP.ID_VP(R15) , R1 

e3AC 

0008 



03AE 

6FF3 

LD 

TEMP.CPU_NUM(R15), R3 

03B0 

000A 



0313H 

6118 

LD 

Re, AFT.RUNNING_LIST(R 1 ^ 

03B4 

0002' 





! RESTORE REMAINING ARGUMENTS ! 

03B6 

61F2 

LD 

R2, TEMP.EVSNT_NR(R15) 

03B8 

0002 



03BA 

61F1 

LD 

Rl, TEMP.HANDLE_PTR(R15) 

e3BC 

0000 





! SAVE EVENT DATA ! 

03BE 

5414 

LDL 

RR4, HANDLE_VAL.HIGK(R1) 

0300 

0000 



03C2 

5De4 

LDL 

APT.AP.HANDLE(R8), RR4 

03C4 

0030' 



0306 

6114 

LD 

R4, HANDLE_VAL.L0'^(R1^ 

0308 

0004 



03OA 

6F84 

LD 

APT.AP.HANDLE[8J(R8), R4 

0300 

0034' 



03OE 

6F82 

LD 

APT.AP.INSTAN0E(R8), R2 

03D0 

0036' 



03D2 

54F6 

LDL 

RR6, TEMP.EVENT_VAL(R15^ 

03D4 

0004 



03D6 

5D86 

LDL 

APT.AP.VALUE(Re), RR6 

03DS 

0038' 





! REMOVE PROOESS FROM READY LIST 

03DA 

6181 

LD 

Rl, A?T.A?.AFFINITY(RS) 

03DO 

0020 ' 



03DE 

6112 

LD 

E2, APT.READY_LIST(R1) 

03E0 

0006' 





! SEE 

IF PROOESS IS FIRST 



ENTRY IN READY LIST ! 

03E2 

8B62 

OP 

P.2, Rg 



IF EQ 

!INSERT NEW READY LIST HEAD 

03E4 

5E0E 

THEN 


03E6 

03F4' 



03E8 

6183 

LD 

R3, APT.AP.NEXT_AP(R81 

03EA 

0020' 
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03EC 

6F13, 

LD 


APT .READY_LIST(H1), R3 

03ES 

0006 




03F0 

5E08 

ELSE 

'.DELETE FROM LIST BODY! 

03F2 

040E ' 

DO 



03F4 

6123 

LD 


R3, AFT.AF.NEXT_AF(R2) 

03F6 

0020' 




03F8 

8B83 

CP 


P3, R8 



IF 

EC 

IFOUND ITEM IN LIST! 

03FA 

5E0E 

THEN 


03FC 

040A' 




03FE 

6183 


LD 

R3, APT.AF,NEXT_AP(R81 

0400 

0020' 




0402 

6F23 


LD 

APT.AF .NEXT_AP(R2) , R3 

0404 

0020' 




04.06 

5E08 


EXIT 

0408 

040E ' 

FI 



040A 

A132 

LD 


R2, R3 

040C 

E8F3 

OD 





FI 





’THREAD 

PROCESS IN BLOCKED LIST! 

040E 

A182 

LD 

R2 

, RS 

0410 

7603 

LDA 

R3 

, AFT.BLOCKED_LIST 

0412 

000A' 




0414 

7604 

LDA 

R4 

, APT.AP.NEXT_AF 

0416 

0020' 




0418 

7605 

LDA 

H5 

, APT.AP.PRI 

041A 

0028 ' 




041C 

7606 

LDA 

R6 

, apt.AP.STATE 

041E 

002A' 




0420 

2107 

LD 

fi7 

, ^BLOCKED 

0422 

0002 




0424 

5F00 

CALL 

LIST INSERT !R2:05J ID 

0426 

0000’!' 





?.3:LIST H3AE FTP. 
R4;NSXT OBJ FTP 
P.biFPlOPITY FTP. 
RetSTATE FTP 
P7:STATB ! 

! GET CURRENT VP ID ! 


0428 

61F1 

LD Rl, TEMP.ID_VP(R15) 

042A 

0008 


042C 

61F3 

LD R3, TEMP.CPU_NUM(R15) 

042E 

000A 

! SCHEDULE FIRST READY PROCESS ! 

0430 

5F00 

CALL TC_GETWORK !R1:VP_ID 

0432 

0000' 

R3:CPU 

! UNLOCK APT ! 

0434 

7604 

LDA R4, APT.LOCK 


14k: 































0436 

0000' 



0438 

5F00 

CALL K UNLOCK 

e43A 

0000=p 

! RESTOKE 

SUCCESS CODE 

043C 

2100 

LD pe, 

#SUCCE£DED 

e43E 

0002 




FI 

FI 




! RESTORE STACK ! 

0440 

0442 

010F 
0012 

ADD 

R15, tfSIZEOF TEMP 

0^44 

9Eee 

RET 


0446 


END TC 

AWAIT 
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t;44:6 


PROCESS_CLASS PROCEDURE 

T Sj* #|i #|*S^ 3^ Sfi «|« »|* 3{« *|S S|% SfC 3fS «|« 2|« SJ? #^5 

^ reads security access 

- CLASS OE CURRENT PROCESS 

- IN APT. CALLED SEG ’•* 
MGR AND EVENT MGR 

^ ^ 9,c ^ s,: :te 


=? LOCAL VARIABLES; - 

'i' Rl: VP ID ’=' 

R5: PROCESS ID 

Xfi #|S 


’P RETURNS : 

RR2: PROCESS SAC 

•*•^5V V W V V W ^V^ V•? J 




ENTRY 


0446 

7604 

LDA 

R4,APT.LOCK 

0448 

0000' 



044A 

5E00 

CALL 

K_LOCK !R4:''aPT.L0CK 

044C 

0000’p 



044E 

5700 

CALL 

RUNNING_VP (RETURNS; 

0450 

0000^* 


Rl;VP ID 




R3:CPU #! 

0452 

6115 

LD 

R5,APT.RUNNING_LIST(R1 

0454 

0002' 



0456 

5452 

LDL 

RR2,APT.AP.SAC(R5) 

0458 

0024' 





! UNLOCK APT ! 

045A 

7604 

LDA 

R4. APT.LOCK 

045C 

0000' 



045E 

5F00 

CALL 

K_UNLOCK 

0460 

0000’!' 



0462 

9E08 

RET 


0464 


END PROCESS CLASS 


14.4 





























0464 


GET_DJBfi_NU^'BER PROCEEUfiE 

’•'• OBTAINS DBR NUMBER EP.OM APT 
FOR THE CURRENT PROCESS. 

’i' callee b^ segment manager 

^ *1? S|* Sg«S^ 2^ «fC iifi ifm 3^ 3^ 3^* 3^C 3,* 3^ 3^« 5gC Sfi Sfi 3^ 3^4 ifi 3^ SJ5 S^i 3^ ^ 3^? Sfi 7fi 7fi 

^ LOCAL VARIABLES: - 

Pi: VP ID 

R5: PROCESS ID - 

3p 3^ 3;c3^ :i;c 3;c 3^ 3^ 3;: 3;e 3^ 3^ 3^ 3;c 3^ 3;c 3^ 3^ 3;e 3^ 3^ 3^ 3^ 3;: 3^ 3^ 3^ 3^ 3;c 3;e 3^ 3^ 

RETURNS: 

’•' Rl: DBP NUMBER - 


ENTR*^ 

!NOTE: DBR # IS ONLY VALID WHILE FROCE 
IS LOADED. THIS IS NO PROBLEM IN SAS 
AS ALL PROCESSES REMAIN LOADED. IN A 
MORE general CASS, THE DBR ^ COULD ONLY 
BE ASSUMED CORRECT WHILE THE APT IS LOCKED 


0464 

0466 

7604 

0000' 

LDA 

R4,APT.LOCK 

046S 
046 A 

5F00 

0000’!' 

CALL 

K_LOCK !R4:''APT.iOCK! 

046C 

5F00 

CALL 

RUNNING_VP ’RETURNS: 

046E 

0000’!' 


Rl:VP ID 
R3:CPU #! 

0470 

0472 

6115 

0002' 

LD 

R5,APT.RUNNING LIST(R1 

0474 

0476 

6151 

0022' 

LD Rl.APT.AP.DBR(R5) 

! UNLOCK APT ! 

0478 
047 A 

7604 

0000' 

LDA 

R4, APT.LOCK 

047C 

047E 

5F00 

0000’!' 

CALL 

K_UNLOCK 

0^80 

9E08 

RET 


0432 


END GET_DBE_NUMBER 


END TC 
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APPENDIX C - EISTRIDUTED MEMORY MANAGER LISTINGS 


Z8000ASM H.02 

LOG OBJ CODE STMT SOURCE STATEMENT 


SLISTON STTY 


DIST_MM MODULE 


CONSTANT 


CREATE CODE 

= 50 

DELETE CODE 

= 51 

ACTIVATE CODE 

= 52 

DEACTIVATE CODE 

= 53 

SWAP IN CODE 

= 54 

swap"otjt_code 

= 55 

NR CPU 

= 2 

NR KST ENTRY 

= 54 

MAX SEG SIZE 

= 12B 

MAX DBR NO 

= 4 

KST SEG NO 

= 2 

NR OF KSEGS 

= 10 

BLOCK SIZE 

= 8 

MEM AVAIL 

= ^F00 

G AST LIMIT 

= 10 

INS'^ANCEI 

= 1 

INSTANCS2 

= 2 

INVALID INSTANCE 

= 95 

SUCCEEDED 

= 2 


TYPE 

H_ARRAY 
COM MSG 
ADDJ?SSS 


ARRAY [3 WORDJ 
ARRA^ [16 BYTE] 
WORD 


G AST_REC RECORD 

TUNIOnE_ID LONG 

GLOBAL_ADDR ADDRESS 

P_L_ASTE_NO WORD 

flag word 

PAH_ASTE WORD 

NR_ACTIVE WORD 

NO_ACT_DEP BYTE 

SIZEl BYTE 

PG_TBL ADDRESS 

ALIAS TBL ADDRESS 


SEOUENCER LONG 
EVENTl LONG 
EYENT2 LONG 

J 
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MM ?P ID 


WORD 


SEG_ARRAY ARRAY [MAI_SEG_SIZE 3YTEJ 

$SECTION D_MM DATA 
GLODAL 

MM_CP'T_TBL ARRAY [NR_CPU MM_7P_IDJ 

^SECTION AVAIL_MEM 
INTERNAL 

! NOTE: MEM_POOL IS LOCATED IN 
CPU LOCAL MEMORY. ! 

0000 MEM_POOL ARRAY [MEM_AVAIL BYTEJ 


GLOBAL 

! NOTE: NEXT_BLOCK IS USED IN THE MM_ALLOCATE 
STUB AS AN offset POINTER INTO THE FLOCK 
OF ALLOCATABLE MEMORY. IT IS INITIALIZED 
IN BOOTSTRAP LOADER. ! 

0F00 NEXT_BLOCK WORD 

SSECTION MSG FRAME_DCL 
INTERNAL 

!NOTE: THESE RECORDS ARE ■’OVERLAYS" OR "FRAMES" USED 
TO DEFINE MESSAGE FORMATS. NO MEMORY IS ALLOCATED ! 
$ABS 0 


0000 

create_msg 

RECORD 

[CR CODE 

CE MM HANDLE 

CE entry no 

CE FILL 

CE SIZE 
CS_CLASS 

WORD 

H_ARRAY 

SHORT integer 
BYTE 

WORD 

LONG] 

0000 

SABS 0 

DELETE MSG 

RECORD 

[DE CODE 

DE MM HANDLE 
DE ENTRY NO 

DE FILL 

WORD 

H ARRAY 

SHORT INTEGER 
ARRAY[7 BYTE] 


0000 


$ABS 0 

ACTIVATE MSG 


RECORD [ACT_CODS WORE 

A_DBR_NO WORE 

A MM HANDLE H ARRAY 


A ENTRY_NO 

a”segment no 

A FILL 


SHOET_INTEGER 
SK0RT_INTEGER 
LONG] 


147 


































0e00 


0000 


0000 


0000 


0000 


0000 


SAES 0 

DEACTIVATE MSG 


$ABS 0 
SWAP IN MSG 


$A£S 0 

SWAP OUT MSG 


$ABS 0 

RET sue CODE 


SABS 0 

R ACTIVATE ARG 


RECORD [DEACT CODE 

WORD 

D DER NO 

WORD 

D MM HANDLE 

H_ARRAY 

d”fill 

ARRAY[3 

RECORD [S IN CODE 

WORE 

SI MM HANDLE 

H ARRAY 

SI DER NO 

WORD 

SI ACCESS AUTH 

[ BYTE 

SI FILLl 


SI_FILL 

ARRAI[2 

RECORD [S OUT CODE 

WORD 

SO DBR NO 

WORD 

SO MM HANDLE 

H ARRAY 

SO_FILL 

ARRAY [3 

RECORD [sue CODE 

BYTE 

SC FILL 

ARRAY [1 

J 


RECORD [R sue CODE 

B'^TE 

r“fill 

BYTE 

R MM HANDLE 

H ARRAY 

R CLASS 

LONG 

R SIZE 

WORD 

R"FILL1 

WORDJ 


WORD]J 


WCRDJ J 


WORD]J 


5 BTTEJ 


SABS 0 

MM_HANDLE RECORD 

[ID LONG 

ENTRY NO WORD 

j 
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EXTL’RNAL 


G_AST_LOCK WORD 

G_AST ARRAYLG_AST_L1MIT G_AST_RECJ 


E_LOCK 

PROCEDURE 

K_UNLOCK 

PROCEDURE 

GET_CPU_NO 

PROCEDURE 

SIGNAL 

PROCEDURE 

WA IT 

PROCEDURE 
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GLOBAL 

$SECTION D_MM_PROC 




mm 030F 
0002 0010 
0004 AlFD 


mm_creatj!J_entry procedure 

>»= interface between seg mgr 

’i' (CREATE_SEG PROCEDURE) AND 
^ MMGR PROCESS (CREATE_ENTRY 
PROCEDURE). ARRANGES AND 
^ PERFORMS I PC. 

SgC^S 2|S ifi 3i|( ?JC 9|S SJl* wji* SgC ifiS^ Sy* 9^ S^C 3JS ffi S||« ^|C ifi 



REGISTER USE: 

5? 


PARAMETERS 

s? 


R0:SUCCESS CODE (RET) 



RltHPTR (INPUT) 



R2:ENTPT NO (INPUT) 



R3:SIZE IlNPUT) 

V 


RR4:CLASS (INPUT) 

a? 


LOCAL USE 



R6:MM handle ARRAY ENTRY 



RB:''COM MSGBUF 



R13:''C0M MSGBUF 



9^9^9fi3^ 


ENTRY 

’USE stack for MESSAGE! 
SUB R15,#SIZE0F C0M_MSG 


LD R13,R15 ! ''COM_MSGBUF ! 


IFILL COM_MSGEUF (LOAD MESSAGE). CREATE MSG 
FRAME IS BASED AT ADDRESS ZERO. IT IS 
OVERLAID ONTO COM_MSGBUF FRAME BY INDEXING 
EACH ENTRI (I.E. ADDING TO EACH ENTRY) THE 
base address OF COM MSGBUF! 


0006 4DD5 LD 

0008 0000 
000A 0032 
000C 3116 LD 

000E 0000 
0010 6FD6 LD 

0012 0002 
0014 3116 LD 

0016 0002 
0018 6FD6 LD 

00lA 0004 
001C 3116 LD 

001E 0004 
0020 6FD6 LD 

0022 0006 
0024 6FD2 LD 


CREATE_MSG.CR_C0DE(R13),#CREATE_C0DE 

R6,R1(#0) !INDET TO MM_HANDLE ENTRY! 
CREATE_MSG.CE_MM_HANDLE[0J (R13),R6 
R6.R1(#2) 

CREATE_MSG.CE_MM_HANDLSL1j(R13),R6 
R6,R1(#4) 

CREATE_MSG.CE_MM_HANDLE1.2J (R13) ,R6 
CREATE MSG.CE ENTRY N0(R13),R2 

































0026 

0008 



0028 

5rD4 

LDL 

CRSATE_MSG.CE_CLASS fR13),RR4 

002A 

000C 



002C 

6FD3 

LD 

CREATE_MSG,CE_SIZE(R13),R3 

002E 

000A 



0030 

AIDS 

ID 

R8,R13 

0032 

5F00 

CALL 

PEREORM_IPC !R8: "COM_MSGBUF! 

0034 

018C' 





IRETRIEVE SUCCESS CODE EROM RETURNEE MESSAGE! 

0036 

8D08 

CLR 

R0 

0038 

60D8 

LDB 

RL0,RET_SUC_CODE.SUC_CODE(H13 ) 

003A 

0000 



003C 

010F 

ADD 

Rl5,ffSIZE0F COM_MSG !P.ESTOR£ STACK STATE! 

003E 

0010 



0040 

9£08 

RET 


0042 

END 

mm_create_entrt 
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MM_DEIi;TE_SNTRT PROCEDURE 

J v VW ^ V V W3i« V ^ 

interface retween SEG mgr ’i' 

’i' (DELETE_SEG PROCEDURE) AND ^ 

^ MMGR (DELETE_ENTRY PROCEDURE).- 
-ARRANGES AND PERFORf^S IPC. 

^ sjc 3(c ^ ^ 9;c s;;^ ^ ^ 9;c V 3 ;: 3^ ^ ^ ^ ^ ^ ^ ^ ^ 

REGISTER USE: 

’J' PARAMETERS ’=' 

’ R0 :SUCCESS_CODE(RET) 

R1 :HPTR( INPUT) 

>i' R2 :£NTRY_NO( INPUT) 

LOCAL USE - 

’i' R6:MM_HANDLE ARRAY ENTRY - 

R8:"C0M_MSGBUF 
R13:"C0M_MSGBUF 

3)* Si» 3|C Sifi 3|S 3|» 3|S 3|( ijfi 3iC 3|S 3|C 3|« Si« 3iS 3^ Sfi 3|« Sjfi 3|* 3|« 3|« 3^ Sjfi SJL | 

ENTRY 

!USE STACK FOR MESSAGE! 


0042 

0044 

030F 

0010 

SUB 

0046 

AlFD 

LD 


Rl3,Rlb ! COM_MSGPUF ! 

IFILL COM_MSGEUF (LOAD MESSAGE). D£LETE_MSG FRAME 
IS BASED AT ADDRESS ZERO. IT IS OVERLAID ONTO 
COM_MSGBUF F^^AME BY INDEXING EACH ENTRY (I.E. ADD¬ 
ING TO EACH ENTRY) THE BASE ADDRESS OF COM MSGBUF! 


0048 

4DD5 

LD 

DELETE_MSG. 

004A 

0000 



004C 

0033 



0 04E 

3116 

LD 

R6,R1(<*0) 

0050 

0000 



0052 

6FD6 

LD 

D£LETE_MSG. 

0054 

0002 



0056 

3116 

LD 

R6,R1(#2) 

0058 

0002 



005A 

6FD6 

LD 

DEiSTE_MSG. 

005C 

0004 



005E 

3116 

LD 

R6,P1(# 4 ) 

0060 

0004 



0062 

6FD6 

LD 

delete_msg.: 

0064 

0006 



0066 

6FD2 

LD 

DELSTE_MSG. 

0068 

0008 



006A 

A1D8 

LD 

R8,R13 

006C 

5F00 

CALL 

PERFORM_IPC 

006E 

018C ' 





’RETRIEVE SUCCESS 

0070 

8D08 

CLR 

R0 

0072 

60D8 

LDB 

RL0,RET_SUC 

0074 

0000 



0076 

010F 

ADD 

R15,#SIZE0F 

0078 

0010 



007 A 

9E08 

RET 


007C 

END 

MM DELETE ENTRY 
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efe;7c 


007C 

0fe57E 

0080 

0082 


0084 

0086 

0088 

008A 

0080 

0e8E 

0090 

0092 

0094 

0096 

0098 

009A 

0090 

009E 

00A0 

e0A2 


MM aotivate FHOOETURE 

V intereaoe between seg mgr - 

(MAKE KNOWN PROOEDURE ^ ANE 

- ^^MGR “ (AOTIVATE PROOEDURE). - 

- ARRANGES AND PERFORMS IPG. - 

5? jp 5?SfC W =!t V 5? sp V JF 5)t 5? s? a? V »!t V W 3? V W sp 5? sp S? ap Sit 



REGISTER USE: 

aji 

V 

PARAMETERS 

a? 

35s 

Rl:DBR NO(INPUT) 

aj' 

a? 

R2:EPTR(INPUT) 

V 


R3;ENTRY NO 

a? 

a? 

R4:S£GMENT NO 

a? 

ajs 

R12;RET HANDLE PTR 

a? 

aiS 

LOCAL USE 

V 

3 ;c 

R8:''C0M MSGBUF 

a? 

a;c 

R13:''C0M MSGBUF 

a? 


RETURNS: 


ajc 

R0:SUCCESS CODE 



RR2:CLASS 



R4:SIZE 

a? 


apapap^itpcptvapjpspjicvpcajepejiesicpcaic^jcpspsaitaic jis:9e5St5iCJie3itptpt;j: } 


ENTR’^ 

!USE STACK FOR MESSAGE! 

030F SUB R15,#SIZE0F COM_MSG 

0010 

AIFD LD R12,R15 ! "COM_MSGBUF ! 

! SAVE RETURN HANDLE POINTER ! 
93FC PUSH 0R15, Rl2 


!FILL COM MSGBUF (LOAD MESSAGE). ACTIVATE_MSG FRAME 

IS based“at address zero, it is overlaid onto 

COM_MSGBUF FRAME BY INDEXING EACH ENTR^ (I .E . ADD¬ 
ING TO EACH ENTRTf) THE BASE ADDRESS OF COM MSGBUF! 


4DD5 

LD 

ACTIVATE_MSG.AC 

T_CODE(R13^,#ACTIVAT 

0000 

0034 

6FD1 

LD 

ACTIVATS_MSG.A_ 

DBR_NO(R13) ,R1 

0002 

3126 

LD 

R6,R2(#0) 


0000 

6 FD6 

LD 

ACTIVATE_MSG.A_ 

MM_HANDLE [0J (R13^ ,R6 

0004 

3126 

LD 

R6,R2(#2) 


0002 

6 FD6 

LD 

ACTIVATE_MSG.A_ 

MM_HANDLSL1J(R13),R6 

0006 

3126 

LD 

R6,R2(#4) 


0004 

6 FD6 

LD 

activate_msg.a_ 

MM_HANDLS|.2J ( H13) , R6 
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eeA4 

0008 



00A6 

eEDB 

LDB 

ACTIVATE_MSG.A_ENTRY_N0(R13),RL3 

00A8 

000A 



00 AA 

6 Erc 

be 

ACTIVATE^MSG.A_SEGMENT_N0(R13'.RL4 

00AC 

000 B 



00AE 

AIDS 

LD 

R8,R13 

0 e£0 

5F00 

CALL 

PERFORM_IPC ! (R8 :''COM_MSGEUF ! 

00 B2 

018C ' 





! RESTORE RETURN HANDLE POINTER ! 

00B4 

97FC 

POP 

R12, 0R15 



! update MN! handle ENTRY ! 

00 £6 

54D6 

LDL 

RR6, R_ACTIVATS_ARG.R_MM_HANDLE(Ri: 

00£8 

0002 



003A 

5DC6 

LDL 

MM_HANDLE.ID(R12), RR6 

00 £C 

0000 



00 £E 

61D5 

LD 

R6,R_ACTIVATE_ARG.R_MM_HANDLE12J(R 

00C0 

0006 



00C2 

6 FC6 

LD 

MM,_KANDLE.ENTRT_N0(R12 ) , Re 

00C4 

0004 





!RETRIEVE OTHER RETURN ARGUMENTS! 

00 C6 

8D08 

CLP 

R0 

00C8 

60D8 

LDB 

RL0,R_ACTIVATE_ARG.H_SUC_CODE(R13) 

00CA 

0000 



00 CC 

54D2 

LDL 

RR2,R_ACTIVATE_ARG.R_CLASS(R13) 

00CE 

0008 



00 D0 

61D4 

LD 

R4,R_ACTIVATE_ARG.R_SIZE(E13) 

00D2 

000C 



00D4 

010F 

ADD 

R15,#SIZS0F COM_MSG 'RESTORE STACK 

00 D6 

0010 



00D8 

9E08 

RET 


00DA 

END 

MM activate 


ATE! 


154 











































eeDA DEACTIVATE FROCEEUKS 

INTERFACE BETWEEN SEG f^GR - 

(TERI^INATE procedure) and '“ 

- rr^GR (deactivate procedure). - 

'•* arranges and performs ipc. 

’p register USE: ^ 

- PARAMETERS - 

RO :SUCCESS_CODE(RET) - 

R1 :DBR_NO( INPUT ) - 

RPtHPTRdNPUT) - 

LOCAL USE 

^ R6 :MM_HANDLE array ENTRY 

- RS :''COM_MSG£UF 

’S' R13:''C0M_MSGBUF ’i' 


ENTRY 


00DA 

030F 

!USE 

SUB 

OODC 

OtJDE 

0010 

AIFD 

LD 


STACK FOR MESSAGE! 
R15,#SIZE0F COM_MSG 

R13,Rlb ! "COM_MSGEUF ! 


IFILL COM_MSGEUF (LOAD MESSAGE). DEACTIVATE_MSG FRAME 
IS BASED AT ADDRESS ZERO. IT IS OVERLAID ONTO 
C0M_MSGBUF frame by INDEXING EACH ENTRY (I .E. ADD¬ 
ING TO EACH ENTRY) THE BASE ADDRESS OF COM MSGBUF! 


00 E0 

4DD5 

LD 

deactivate. 

MSG.DEACT C0DS(R13^, 

00E2 

0000 



#dsactivate,code 

00S4 

0035 




00E6 

6FD1 

LD 

deactivate. 

MSG.D_DBR_NO(R13),R1 

00E8 

0002 




00EA 

3126 

LD 

R6,R2(#0) 

! INDEX TO MM,HANDLE ENTRY! 

00EC 

0000 




00EE 

6FD6 

LD 

deactivate. 

MSG.D,MM,EANELE[0j(R13),R6 

00F0 

0004 




00F2 

3126 

LD 

R6,R2(#2) 


00F4 

0002 




00Fe 

dFD6 

LD 

deactivate_ 

MSG.D_MM,HANDLE[1J(R13),R6 

00 Fe 

00 06 




00FA 

3126 

LD 

R6,R2(#4) 


00FC 

0004 




e0FE 

6FD6 

LD 

deactivate. 

MSG.D_MM,HANDLEt2j(R13),R6 

0100 

0008 




0102 

A1D8 

LD 

R8,R13 


0104 

5F00 

CALL 

PERFORM_IPC 

!R8: ''COM,MSGBUF! 

0106 

018C ' 





155 






















































IPJiTHIKVE SUCCESS CODE FROM RETURNED MESSAGE! 


feJlee 8D08 
iJlfeJA 60D8 
010 C 0000 
010 E 0ieF 
0110 0010 
011 ii 9E08 
0114 END 


CLR R0 

LDB RL0,P.ET_SUC_COD£.SUC_CODE(P13) 

ADD R15,#SIZE0F COM_MSG IRESTOflS STACK STATS 
RET 

MM DEACTIVATE 


156 





































0114 


MM S5VAP IN PROCEDUHI 


interface between seg mgr (SM_’^ 

- SWAP IN PROCEDURE) AND MMGR - 
(SWAP IN PROCEDURE). ARRANGES 


’i' AND PERFORMS IPC . - 

V fi* ^ n* *n W ^ 5i! S,S 3Jt 3,5 J|5 5ifi i,S SjC 2,t 5;^ J,; S|C J|S J,S Ji? 5,5 5,% 


3?: 

REGISTER USE; 

3»* 


PARAMETERS 

3|2 

3? 

R0:SUCCESS CODS(RST) 

3i* 

3;s 

Rl;DBK NO(INPUT) 


3? 

R2:KPTR(INPUT) 

3J5 


R3;ACCESS (INPUT) 

3|5 


LOCAL USE 

3^ 

3? 

R6;MM HANDLE ARRAY ENTRY 


3|5 

R8;''C0M MSGBUF 

3.i 


R13:''C0M MSGBUF 

3?S 


5?3i5 3{s5;ca?:3;cs;55?ap3pi;e3?:3;ea?:jicj;c3ica?:3?:3?:>^3^>i6j;c>?a?:3?>;eapj;s5^5icap j 


SNTRT 

!USE stack FOR MESSAGE! 

0114 030F SUB R15,#SIZEOF COM_MSG 
0116 0010 

0118 AIFD LD R13,R15 1 ''COM MSGBUF ! 


!FILL COM MSGBUF (LOAD MESSAGE). SWAP_IN_MSG FRAME 
IS BASSD'aT address zero. IT IS OVERLAID ONTO 
COM_MSGBUF FRAME BY INDEXING EACH ENTRY (I.E. ADD¬ 
ING TO EACH SNT?.^) THE BASS ADDRESS OF COM MSGBUF! 


011A 

4DD5 

LD 

011C 

0000 


011 E 

0036 


0120 

3126 

LD 

0122 

0000 


0124 

6 FD6 

LD 

0126 

0002 


0128 

3126 

LD 

012A 

0002 


012C 

6 FD6 

LD 

012E 

0004 


0130 

3126 

LD 

0132 

0004 


0134 

6 FD6 

LD 

0136 

0006 


0138 

6 FD1 

LD 

013A 

0008 


013C 

6 EDB 

LDB 

013E 

000A 


0140 

A1D8 

LD 

0142 

5F00 

CALL 

0144 

018C ' 



SWAP_IN_MSG.S_rN_C0DE(R13),#SWAP_IN_CODE 

R6,R2(#0) ’INDEX TO MM_HANDLE ENTRY! 
SWAP_IN_MSG.SI_MM_HANDLEleJ(R13),R6 
R6,P2(#2) 

SWAP_IN_MSG.SI_MM_HANDLE[1J(R13>,R6 
R6,R2(#4) 

SWAP_IN_MSG.SI_MM_KANDLE[2J (R13) ,R6 
SWAP_IN_MSG.SI_DBR_N0(R13),R1 
SWAP_IN_MSG.SI_ACCESS_AUTH(R13URL3 
H6 R1 

PERFORM IPC !R8: ''COM MSGBUF! 
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!T?iiTRIJ!;VE SUCCESS CODE FROM RETURNEE ^^ESSACE! 


65146 

eD08 

CLR 

H0 

0148 

014A 

60D8 

0000 

LDB 

RL0,RET_SUC_CODE.SUC_CCEE(R13) 

014C 

014E 

010 F 

0010 

ADD 

R15,#SIZE0E COM_MSG IRESTORS STACK 

0150 

9E08 

RET 


0152 

END 

MM_SWAP_IN 
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0152 PROCEEURE 

f ^*3^ i|S 5,5?5? S|S S,S SJC S|t Si* SJt 5^5 5JS3,C 5,* SfiXfi ifiSfi 3^ Sjfi i^t3^ 9^ ifi 

interface between seg r^GR {sy\_^ 

SWAP_OUT PROCEDURE) AND f^MGR 
^ (SWAP_OUT PROCEDURE). ARRANGES- 

AND PERFORMS IPC. ’i' 

9^ ^ 3JC 3^ 3^ 3^ 3^ ;;c ^ 3;c 9iC 31$ );c V ^ ^’ic 7 ^ 3jC 

- REGISTER USE: - 

^ PARAMETERS ’s' 

=5* R0:SUCCESS_CODE(RET) 

- Rl:DBR NO(INPUT) - 

’P R2:HPTR(INPUT) 

^ LOCAL USE - 

- R6:MM HANDLE ARRAY ENTRY - 

=!' Re :''C0M_MSGBDF 

R13:''C0M_MSGBUF ^ 

ENTRY 

!USE STACK FOR MESSAGE! 


0152 

030F 

SUB 

R15,#SIZE0F 

COM_MSG 

0154 

0156 

0010 

AlFD 

LD 

R13.R15 ! 

''COM MSGBUF ! 


!FILL COM MSGEUF (LOAD MESSAGE). SWAP_OUT_MSG FRAME 

IS based”at address zero, it is overlaid onto 

COM_MSGBUF FRAME BY INDEXING EACH ENTRY (I.E. ADD¬ 
ING TO EACH ENTRY) THE BASE ADDRESS OF COM MSGEUF! 


0158 

015A 

015C 

4DD5 

0000 

0037 

LD 

SWAP_OUT_MSG. 

015E 

0160 

3126 

0000 

LD 

R6,R2{#0) !I 

0162 

0164 

6 FD6 

0004 

LD 

SWAP_OUT_MSG. 

0156 

0168 

3126 

0002 

LD 

R6,R2(<#2) 

016A 

016C 

6 FD6 

0006 

LD 

SWAP_OUT_MSG. 

016E 

0170 

3126 

0004 

LD 

R6,R2(#4) 

0172 

0174 

6 FD6 

0008 

LD 

SWAP_OUT_MSG. 

0176 

0178 

6 FD1 

0002 

LD 

SWAP_OUT_MSG. 

017A 

AIDS 

LD 

RB,R13 

017C 

017E 

5F00 

018C' 

CALL 

PERFORM_IPC 


S_0DT_C0DE(R13) , #SWAP_OUT_CODE 

NDEX TO MM_HANDLE ENTRY! 
SO_MM_HANDLE[0](R13),R6 

SO_mm_HANDLE[1J (R13^,R6 

S0_MM_EANDLE[2J(R13).RG 
S0_DBR_N0(R13) ,R1 

!R8: ''COM MSGBUF! 
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IRSTRIEVE SUCCESS_CODE FROM RETURNED MESSAGE! 
0180 8D08 CIR fiO 

0182 80D8 LDB RL0,RET_SUC_CODE.SUC_CODE(R13) 

0184 0000 

0186 010F ADD R15,#SIZE0F COM_i^SG IRESTORE STACK STATE 

0188 0010 
018A 9E08 RET 

018C END MM SWAP OUT 
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PSPrORM IPC PROCEEURi 

SERVICE ROUTINE TO ARRANGE AND - 
PERFORM IPC WITH THE MEM MGR PROC ’=' 

V ^ ^ ^ 3;e sp 3ic 3^ :;e :;c 3^3^ 3ic sfc 3ic :;e :;c>^ ^ 3 ;: 3^ ^ ^ 5jc 3;c :;c ^ 


¥ 

REGISTER USE: 


39c 

PARAMETERS 

3?: 

nC 

R8: ''C0m_MSG(INPUT) 

3r 

V 

LOCAL USE 

3f5 

5? 

Rl,Rli: WORK REGS 

3? 

3JC 

R4: ''G AST LOCK 


5.S 

R13: ''COM MSGRUF 

3r 


3{C3iC3iC3JCS?S;«3SC3SCS;c3iC:i63p3{C5je3JS3«63}6 5?3gC3p3;C3;CS;C3p3;C3p:iC3ie3SC3JC3;C3iC3?3iC3iC3JC:iC I 




ENTRY 


018C 

93FD 

PUSH 

eRl5,R13 !''COM MSGRUF! 

018E 

5F00 

CALL 

GET_CPU_NO !RET-Rl;CPU_NO! 

0190 

0000=!' 



019H 

A112 

LD 

R2,R1 

0194 

6121 

LD 

R1,MM_CPU_TSL(R2) !MM_VP_ 

0196 

0000' 



0198 

7804 

LDA 

R4,G_AST_LOCK 

019A 

0000=!' 



019C 

5F00 

CALL 

K_LOCK 

019E 

0000V 



01A0 

5F00 

CALL 

SIGNAL !R1 :MM_VP_ID,Rg:''C 

01A2 

0000V 



01A4 

97FD 

POP 

R13,PR15 

01A6 

AIDS 

LD 

Re,Rl3 !''COM MSGRUF! 

01A8 

9 3 ED 

PUSH 

PR15,R13 

01AA 

5F00 

CALL 

wait !R8:''C0M_MSGBUF! 

01AC 

0000=^' 



01AE 

7604 

LDA 

R4,G_AST_10CK 

01E0 

0000V 



01R2 

5F00 

CALL 

K_UNLOCK 

01B4 

0000V 



01B6 

97FD 

POP 

R13,0R15 

eiiJ8 

9E08 

RET 


01BA 

END 

PERFORM IPC 
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ai3A 


01BA E331 
01BC 0006 


01BB 6104 
01C0 0F00' 
01C2 7642 
01C4 0000' 
eiC6 8134 


0ice 6F04 
01CA 0F00' 
01CC 9E08 
01CE 


MM_ALLCCATS PROCEDURE 

’i' ALLOCATES BLOCKS OF CPU=«‘ 

LOCAL r^EMORY. EACH 
BLOCK CONTAINS 256 - 

BYTES OF MEMORY. 

^ :;c;g; :;c 3ic>ic 2 ic 7^ ;gc ^ ^ ^ 

»•' PARAMETERS: 

’i' R3: # OF BLOCKS 

RETURNS: 

R2: STARTING ADDR “s* 

LOCAL: 

^ R4: BLOCK POINTER 

ENTRr 

! NOTE: THIS PROCEDURE IS ONLY A STUB 
OF THE ORIGINALLY DESIGNED MEMORY 
ALLOCATING MECHANISM. IT IS USEE 
BY TEE PROCESS MANAGEMENT DEMONSTRATION 
TO ALLOCATE CPU LOCAL MEMO?.I FOR ALL 
MEMORY ALLOCATION REQUIREMENTS. IN AN 
ACTUAL SASS ENVIRONMENT, THIS WOULD 
BE BETTER SERVED TO HAVE SEPARATE 
ALLOCATION PROCEDURES FOR KERNEL AND 
SUPERVISOR NEEDS. (E.G., KERNEL_ALLOCATE 
AND SUPERVISOR_ALLOCATE). ! 

! COMPUTE SIZE OF MEMORY REQUESTED ! 

SLL R3, #BLOCK_SIZE 

! COMPUTE OFFSET OF MEMORY THAT IS 
TO BE ALLOCATED ! 

LD R4, NEXT_BLOCK lOFFSET! 

LDA R2, MEM_POOL(R4) I START ADDR! 

ADD R4, R3 lUPDATE OFFSET! 

! UPDATE OFFSET IN SECTION OF AVAILABLE 
MEMORY TO INDICATE THAT CURRENTLY 
REQUESTED MEMORY IS NOW ALLOCATED ! 

LD NEXT_BLOCK, R4 !SAVE OFFSET! 

RET 

END MM ALLOCATE 
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eiCE 


01CE 93F1 

01D0 7604 
01D2 0000'!' 
01D4 5F00 
01D6 0000’'' 

01D8 97F1 

01DA 6118 
01DC 0004 

01DE 5486 
01E0 0014’" 

01E2 9464 


01E4 1606 
01E6 0000 
01E8 0001 

01EA 5E86 
01EC 0014’" 


01EE 91F4 
01F0 7604 
01F2 0000*" 
01F4 5F00 
01F6 0000!" 

01F8 95F4 
01FA 9E08 
01FC 


MM TICKET PROCEDURE 

I :!<;p:;(itc:gc;tc:gC}i;;tc:gc;tC3gc:ge3ic:g(^M«^9iC3tc:gC9;c:;c3^:g(:togc:«c 

RETURNS CURRENT VALUE OF 
=" SEGMENT SEQUENCER AND 
’" INCREMENTS SEQUENCER VALUE’" 

=" FOR NEXT TICKET OPERATION 

PARAMETERS: 

Rl: SEG HANDLE PTR 
=" RETURNS: 

=" RR4: ticket VALUE 
=" LOCAL VARIABLES: 

’" RR6: SEQUENCER VALUE 
’" R8: G_AST ENTRY # 

ENTRY 

! SAVE HANDLE PTR ! 

PUSH GR15, Rl 
! LOCK G_AST ! 

LDA R4, G_AST_LOCK 

CALL K_LOCK 

! RESTORE HANDLE PTR ! 

POP Rl, 0R15 
! GET G_AST ENTRY # ! 

LD R8, MM_HANDLE.ENTRY_NO(Rl) 

! GET TICKET VALUE ! 

LDL RR6, G_AST.SE0UENCER(R8) 

! SET RETURN REGISTER VALUE ! 

LDL RR4, RR6 
!ADVANCE SEQUENCER FOR NEXT 
TICKET OPERATION! 

ADDL RR6, #1 


! SAVE NEW SEQUENCER VALUE IN G_AST 
LDL G_AST.SEQUENCER(R8), RR6 

! UNLOCK G_AST ! 

! SAVE RETURN VALUES ! 

PUSHL 0R15, RR4 
LDA R4, G_AST_LOCK 

CALL K_UNLOCK 

! RETRIEVE RETURN VALUES ! 

POPL RR4, OR15 
RET 

END MM TICKET 
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01PC 


MM_READ EVENTCOUNT PROCEDURE 

I :(c9gc3^]i;ic:^;;c9gc3^:(cjte9ic]p)ie svelte 

READS CURRENT VALUE OF THE 
^ EVENTCOUNT SPECIFIED £Y THE =" 
USER. 

s;; 9QC V 9(r V 3? V ^ ^ ^ V ^ 

PARAMETERS: 

Rl: SEG HANDLE PTR » 

R2: INSTANCE (EVENT #) 

:^3^9ge^9ge99e:;c9^^:;c9ge^9Qe3^9ee9Qe9Qc:;c9Qe:;c:sc9Qc :?:^9^9;e^9ee9ee:?:^ 

’i' RETURNS: 

’i' RR4: EVENTCOUNT VALUE 

;;c:;c ^ 9^ qc :;c :;c :;c jgc jgc ;;c V:((:;(>)c igc ;;c:((:((sgc :;c :;c jgc 9^ jgc qc 

LOCAL VARIABLES: ’=» 

RR6: SEQUENCER VALUE >=' 

R8: G_AST ENTRY # 

:^9;e9?V9;<V:tc3tE9;c9P9!t9g(9p:v9?9i(9p9^9gc9gc9p9;c9(c9^3!c:tc9P9p3(c9gc:;c t 


ENTRY 

! SAVE INPUT PARAMETERS ! 


01FC 

93F1 

PUSH 

0R15, Rl 

01FE 

93F2 

PUSH 

0R15, R2 



! LOCK 

. G AST ! 

0200 

7604 

LDA 

R4T g_ast_lock 

0202 

0000*^ 



0204 

5F00 

CALL 

K_LOCK 

0206 

00005 ? 





! RESTORE INPUT PARAMETERS 

0208 

97F2 

POP 

R2, 0R15 

020A 

97F1 

POP 

Rl, 0R15 



! GET 

G AST ENTRY # ! 

020C 

6118 

LD 

R8, MM_EANDLE.ENTRY_ 

020E 

0004 





! READ 

^ EVENTCOUNT ! 



! CHECK WHICH EVENT #. ! 



IF R2 

0210 

0B02 

CASE 

#INSTANCE1 THEN 

0212 

0001 



0214 

5E0E 



0216 

0224' 



0218 

5484 

LDL 

RE4, G_AST.EVENT1( 

021A 

0018’!' 



021C 

2100 

LD 

R0, "SUCCEEDED 

021E 

0002 



0220 

5E08 

CASE 

#INSTANC£2 TEEN 

0222 

023C' 



0224 

0E02 



0226 

0002 



0228 

5E0E 



022A 

0238' 



022C 

5484 

LDL 

RR4, G_AST.EVENT2( 
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022E 

0010’^ 



0230 

2100 

LD 

R0, #SUCCEEDED 

0232 

0002 



0234 

5E08 

ELSE 

.'INVALID INPUT! 

0236 

023C' 



0238 

2100 

LD 

R0, #INVALID_INSTANCE 

023A 

005F - 





FI 




f NOTE 

: NO VALUE IS RETURNED IF 



USER 

SPECIFIED INVALID EVENT 



! SAFE 

RETURN VALUES ! 

023C 

91F4 

FUSEL 

(?R15, RR4 



! UNLOCK G AST ! 

023E 

7604 

LDA 

R4, G_AST_LOCK 

0240 

0000* 



0242 

5F00 

CALL 

K_UNLOCK 

0244 

0000* 





! RESTORE RETURN VALUES ! 

0246 

95F4 

POPL 

RR4, 0R15 

0248 

9E08 

RET 


024A 


END MM 

_read_eventcount 
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024A 


mm_advanc]!: procedure 

’i' DETERMINES G_AST OFFSET FROM 
SEGMENT HANDLE AND INCREMENTS 
THE INSTANCE(EVENT #) SPECIFIED - 
BY TEE CALLER. THIS IN EFFECT 
ANNOUNCES THE OCCURRENCE OF THE “i* 
^ EVENT. THE NEW VALUE CF THE 
EVENTCOUNT IS RETURNED TO THE 
^ CALLER. 

V ^ 3(t V 3^ V W 39 c 3is >ic V ait V 37 3tt W Jtt 9 9 V W 

PARAMETERS : ’i* 

Rl: HANDLE POINTER 
R2: INSTANCE (EVENT #) 

3^ 9QC 99 c aQcsgc > 9 c 3^ 3^ 3QC 9^ aic 99 c 3^ 3^ :qc ^SQc 3^ 3^ sje 3ic 3^ 9^ 9^ age ^ 

^ RETURNS: 

'i' RR2: NEW EVENTCOUNT VALUE v 

jgtajcj^ Jjejie:gc!(e5iejjtv>it3je3iew39e>it5!e5!t3!e3tc^e>!e>i;jiej(ev:9«»5!e»)tqejiejic3it 1 


ENTRY 

! SAVE INPUT PARAMETERS ! 


024A 

93F1 

PUSH 

0R15, Rl 

024C 

93F2 

PUSH 

GR15, R2 



! LOCK 

; G AST ! 

024E 

7604 

LDA 

R 4 T g_ast_lock 

0250 

0000J9t 



0252 

5F00 

CALL 

K_LOCK 

0254 

0000^^ 





! RESTORE INPUT PARAMETERS 

0256 

97F2 

POP 

R2, PR15 

0258 

97F1 

POP 

Rl, 0R15 



! GET 

G AST OFFSET ! 

025A 

6114 

LD 

R4, MM HANDLE.ENTRY 

025C 

0004 





! determine INSTANCE ! 



IF R2 

02bE 

0E02 

CASE 

#INSTANCE1 THEN 

0260 

0001 



0262 

5E0E 



0264 

027C' 



0266 

5442 

LDL 

RR2, G^AST.EVENTlC 

0268 

0018=^ 



026A 

1602 

ADDL P.R2, #1 

026C 

0000 



026E 

0001 





! SAVE NEW EVENTCOUNT ! 

0270 

5D42 

LDL 

G_AST.EVENT1(R4) , . 

0272 

0018^ 



0274 

2100 

LD 

R0, ^SUCCEEDED 

0276 

0002 



0278 

5E08 

CASE 

#INSTANCE2 THEN 
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027A 

029E' 



027C 

0B02 



027 E 

0002 



0280 

5E0E 



0282 

029A' 



0284 

5442 

LDL 

RR2, G_AST.EVENT2(R4) 

0286 

0010’=' 



0288 

1602 

ADDL 

RR2, #1 

028A 

0000 



028C 

0001 





! SAVE NE’# EVENTCOUNT ! 

028E 

5D42 

LDL 

G_AST.EVSNT2(R4), RR2 

0290 

0010’^ 



0292 

2100 

LD 

R0, #SUCCEEDED 

0294 

0002 



0296 

5E08 

ELSE 

!INVALID INPUT! 

0298 

029E' 



029A 

2100 

LD 

R0, #INVALID_INSTANCE 

029C 

005F 





El 




! NOTE 

: AN INVALID INSTANCE VALUE 



WILL 

NOT AFFECT EVENT DATA ! 



I UNLOCK C- AST ! 

029E 

7604 

LDA 

R4, G_AST_L0CK 

02A0 

0000’!' 



02A2 

5F00 

CALL 

K_UNL0CK 

02A4 

0000 V 



02A6 

9E08 

PET 


02A8 


END MM 

advance 


END DIST MM 
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APPENDIX D - GATE KEEPER LISTINGS 


ZSfe50k5ASM 2,02 

LOG OBJ CODE ST'^T SOURCE STATEN-ENT 


KERNEL_GATE_KEEPER MODULE 

$LISTON STTY 


CONSTANT 

ADVANCE_CALL 
AWAIT_CALL 
CREATE_SEG CALL 

deletb_seg“call 

MAKE_KNOWN_CALL 

READ_CALL 

SM_SWAP IN CALL 

?M_SWAP~OUT_CALL 

TERMINAfE_CALL 

TICKET_CALL 

WRITE_CALL 

writeln_call 

CRLF_CALL 

WRITE 

WRITELN 

CRIP 

MONITOR 

REGISTER_BLOCK 
TRAP_CODE_OFFSET 
INVALID KERNEL ENTRY 


1 

2 

3 

4 

5 

6 

7 

8 
9 


10 

11 

12 

13 

ZZYCS 

!PRINT 

CHAR! 

^0FC0 

’.PRINT 

MSG ! 

^eFD4 

! CAR R 

ET/LINE FEED! 

%A902 

32 

36 

%hkD 




global 

GATE KEEPER ENTRY LABEL 


EXTERNAL 

ADVANCE 

AWAIT 

CREATE_SEG 
DELETE SEG 
MAKE KNOWN 

read" 

SM_SWAP_IN 

SM_SWAP_OUT 

terminate 

TICKET 
KERNEL EXIT 


PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

PROCEDURE 

LABEL 


INTERNAL 

SSECTION KERNEL GATE PROC 
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eee'fe) 


GATE KEEPER MAIN 


PROCEDURE 


0000 030F 
0002 0020 
0004 1CF9 
0006 010E 

0008 93P2 
000A 7D27 

000C 2DF2 

000E 93F2 

0010 31F2 
0012 0024 


0014 8C28 


0016 0£02 
0018 0001 
001A 5E0E 
001C 0028' 
001 E 97F2 
0020 5F00 
0022 0000’!' 
0024 5E0S 
0026 010C' 
0028 0P02 
002A 0002 
002C 5E0E 
e02E 003A' 
0030 97F2 
0032 5F00 
0034 0000’" 
0036 5E08 
0038 010C' 
003A 0P02 
003C 0003 
003E 5E0E 
0040 004C' 


ENT?’’’ 

GAT*E_KSEPER_ENTRr : 

! SAVE REGISTERS ! 

SUB R15, #REGISTER_BLOCX 

LDM (?R16, Rl, #16 

! SAVE NSP ! 

PUSH 0R15, R2 
LDCTL R2, NS? 

! RESTORE INPUT REGISTERS ! 

EX R2, 0R16 
! SATE REGISTER 2 ! 

PUSH GR15, R2 
! GET SYSTEM TRAP CODE ! 

LD R2, R15(#TRAP_C0DE_0FFSET) 

! REMOVE SYSTEM CALL IDENTIFIER FROM 
SYSTEM TRAP INSTRUCTION ! 

CLRB RH2 

! NOTE: THIS LEAVES THE USER VISI3LF; 

EXTENDED INSTRUCTION NUMBER IN R2 ! 

! DECODE AND EXECUTE EXTENDED INSTRUCTION 
IF R2 

! NOTE: THE INITIAL VALUE FOR REGISTER 2 
'VILL BE RESTORED WHEN THE APPROPRIATE 
CONDITION IS FOUND ! 

CASE #ADVANCE CALL THEN 


POP R2, 0R15 
CALL advance 

CASE #AWAIT CALL THEN 


POP R2, (?R15 
CALL AWAIT 

CASE #CREATE SEG CALL TEEN 


I 
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97F2 

POP 

R2, ORlb 


t?044 

5E00 

CALL 

CREATE_SEG 


0046 

0000 »i‘ 




0046 

5E08 

CASS 

/jdelete_seg_call 

THEN 

004A 

010C ' 




004C 

0 E02 




0e4E 

0004 




0050 

5E0E 




0052 

005E' 




0054 

97F2 

POP 

R2, 0R15 


0056 

5F00 

CALL 

DELETE_SEG 


0058 

0000 ’i» 




00 5A 

5E06 

Case 

#MA5S_£N0WN_CALL 

THEN 

005C 

010C ' 




005E 

0 B02 




0060 

0005 




0062 

5E0E 




0064 

0070' 




0066 

97F2 

POP 

H2, (?R15 


0068 

5F00 

CALL 

MAKE_KNOVN 


006A 

0000 '* 




006C 

5E08 

CASE 

#READ_CALL THEN 


006E 

010C ' 




0070 

0E02 




0072 

0006 




0074 

5E0E 




0076 

0082' 




0078 

97F2 

POP 

R2, ORlb 


007A 

5F00 

CALL 

read 


007C 

0000 Sr 




007E 

5E08 

CASE 

i*SM_SWAP_lN_CALL 

then 

0080 

010C ' 




0082 

0 E02 




0084 

0007 




0086 

5E0E 




0088 

0094' 




008A 

97F2 

POP 

R2, GR15 


008C 

5F00 

call 

SM_SWAP_IN 


008S 

00005? 




0090 

5E08 

CASE 

#SM_S’rfAP_OUT_CALL 

THE 

0092 

010C ' 




0094 

0 E02 




0096 

0008 




0098 

5E0E 




009A 

00A6' 




009C 

97F2 

POP 

R2, C“Rlb 


009E 

5F00 

CALL 

S^^_SWAP_OUT 


00A0 

0000V 




00A2 

5E08 

CASE 

^TERriINATE_CALL 

THEN 

00A4 

010C' 




00A6 

0 B02 






I 



eeAS 

0009 


04JAA 

5 S0E 


00AC 

00B8 ' 


00AE 

97F2 

POP R2, ORlb 

00 B0 

5F00 

CALL TERI^INATE 

00 B;i 

0000 ^^ 


00B4 

bE08 

CASE ^TICKBT_CALL TPEN 

00B6 

010C ' 


00 B8 

0 E02 


00BA 

00 0A 


00 BC 

5E0E 


00 BE 

00CA' 


00C0 

97F2 

POP R2, 0R15 

00C2 

5F00 

CALL TICKET 

00C4 

0000W 


00 C6 

5E08 

CASE #WRITE_CALL THEN 

00C8 

010C' 


00CA 

0B02 


00CC 

000B 


00 CE 

5E0E 


00 D0 

00DC ' 


0 eD2 

97F2 

POP R2, ORlb 

00D4 

5F00 

CALL WRITE 

00D6 

0 FC8 


0 eDe 

5E08 

CASE ?jWRIT£LN_CALL THEN 

00 DA 

010C ' 


00DC 

0 B02 


00 DE 

0000 


00E0 

5E0E 


00E2 

00EE' 


00E4 

973’:i 

POP R2, 0R15 

00E6 

5F00 

CALL WRITELN 

00 E8 

0 FC0 


00EA 

5E08 

CASE *CRLF_CALL THEN 

00EC 

010C ' 


00EE 

0 B02 


0010 

000 D 


00 F2 

5E0E 


00F4 

0100 ' 


0 eF6 

97F2 

POP P2, ORlb 

00FS 

5F00 

CALL CP-LF 

00FA 

0FD4 


0eFC 

5E08 

ELSE 'INVALID KERNEL INVOCATION! 

00FE 

010 C ' 

! RETURN TO f^ONITOR ! 

! NOTE; THIS RETURN TO MONITOR IS 



FOR STUB USE ONLY. AN INVALID 
KERNEL INVOCATION WOULD NORMALLY 
RETURN TO USER. ! 

0100 

7601 

LDA Rl, $ 

0102 

0100 ' 
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fe51fe:4 210Z 
0106 0EAD 
0108 5F00 
eieA Ay02 


010 C 93F1 

010E 34F1 
0110 0004 


0112 1C19 
0114 010F 


0116 2rFl 

0118 33F1 
011A 0004 

011C 97F1 

011 E 33F1 
0120 001E 


LD H0, #INVALID_KERNEL_ENTRY 
CALL ^'0NIT01^ 


FI 

! 5A^E REGISTERS ON KERNEL STACK ! 
! SAVE R1 ! 

RUSK GR15, R1 

! GST ADDRESS OF REGISTER BLOCK ! 
LDA Rl, R15(#r4) 

! SAVE REGISTERS IN REGISTER BLOCK 
ON KERNEL STACK. ! 

LDM ORl, Rl, #16 

! RESTORE Rl BUT MAINTAIN ADDRESS 
OF REGISTER BLOCK ! 

EX Rl, PR15 

! SAVE Rl ON STACK ! 

LD R15(#4), Rl 

! RESTORE REGISTER BLOCK ADDRESS ! 
ROP Rl, riRib 

! SAVE VALID EXIT SR VALUE ! 

LD R15(#30), Rl 


! EXIT KERNEL BY MEANS OF EARD’ifARF 
PREEMPT HANDLER ! 

0122 5E08 JP KERNEL EXIT 
0124 0000’i' 

0126 END GATS_KEEPER_MAIN 

END KERNEL GATE KEEPER 
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Z6000*SM 2.02 

LOG ** OSJ CODE STf^T SOURCE STATEI^ENT 


USER_GATE MODULE 

$LISTON $TTY 


CONSTANT 

AEVANCE_CALL := 1 

AWAIT CALL := 2 

CREATE_SEG_CALL := 3 

DELETE_S£G_CALL := 4 

MA5E_KN0WN_CALL := b 

REaD_CALL := 6 

SM_SWAP_IN CALL := 7 

SM SVAP_OUT_CALL := b 

TEPMINATE_CALL := 9 

TICKET_CALL := 10 

WRITE_CALL := 11 

WRITELN_CALL := 12 

CRLF call := 13 


GLOBAL 

^SECTION USER_GATE_PROC 


0000 


0000 7F01 
0002 9E08 
0004 


ADVANCE PROCEDURE 

^ PARAMETERS: 

Rl: SEGMENT ft 

^ R2:INSTANCE (ENTRY#^^ 

jp jp V V V ?! 3? 5)t V sp s? JSt S? 5iS V W 

- RETURNS: - 

R0:SUCCESS CODE 

^! V?'?t?I3p3P?£?!3pS?3P5P?!3psp?t3P3pSp?!5p3P!P I 

SNTR^ 

SC #ADVANCE_CALL 
RET 

END ADVANCE 


0004 AWAIT PROCEDURE 


V 

PARAMETERS: 

5;« 


Rl:SEGMENT # 



R2:INSTANCE 



RR4:SPECIFIED VALUE 


3JC ^ic 3;c 3^ 5^5iC 3JC 39c :jc 3JC 5iC 5^ 5^ age 5^ 5^ S?5jC 5;c age JJC 


RETURNS: 


a? 

R0:SUCCESS CODE 



ENTRY 
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#AWAIT CALL 


ee!e)4 7F02 SC 

0005 9E0e RET 

0008 END AWAIT 


0008 


0008 7F03 
000A 9E0e 
000 C 


create_seg procedure 

f 5|S5|5 iJS 3^5 SJC 5^ 5|S S,S SJtJjiSSi; ^ SgCiiS 5,C 5,65^ 5i5?J5 5^5 

=«' PARAMETERS : -i* 

'•i' Rl:MENTOR_SSG_NO 

R2:ENTRT_N0 >•' 

- R3:SIZ£ ’i' 

- RR4: CLASS 

^ W W W V ^ V W V 9 V ^ 

=5' RETURNS: ^ 

R0:SUCCESS CODE - 

♦!• W ^ S|C 5^ SJC i|S SJC 3? JjC ^ 2;; 5^ ;,J 3Jf 3^ S^C ^$Si« 3;«3^ 3^ f 

ENTRY 

sc #CREATE_SEG_CALL 
RET 

END CREATE SEG 


000C 


000C 7F04 
000E 9Eee 
0010 


DELETE_SEG PROCEDURE 

I ffi 3|«3^«3|» 3^^ 3|S ^3|S SJS ^ 3|* S^3|^ ^ 3|S ^C3^ S|C 3^3^ 3^3|C 3^ 

PARAMETERS : 

- Pl:MENTOR_SEG_NO 

- R2:ENTRY_N0 - 

5? iff V Sr W W V iff !1« V ;?e V 5 ;e V V 5? 

=" RETURNS : 

R0: sue CESS CODE - 

:;:9;;(9;cntiffiff iffiffiffiffiff iff’riff’ffiffiff^^iff iff^>ff j 

ENTRY 

SC #DELETE_SEG_CALL 
RET 

END DELETE SEG 


0010 


0010 7P05 

0012 9E0e 

0014 


MAKE_KNOWN PROCEDURE 



PARAMETERS: 

2? 


Rl:MENTOR SEG NO 

•iS 


R2:ENTRY NO 



R3:ACCESS DESIRED 


2iS 2|53*5 3i» 2^2J|C 3^ 3^» 3,? 3|3 3^« 3^ 3)* 3i|C 3,5 3|53^ J 

315 3,5 


RETURNS: 



R0:SUCC£SS CODE 



RlrSEGMENT # 



R2:ACCESS ALLOWED 

2? 


3}:i::3:eVV>)lVWWWW>t:W^^WVsf t 

ENTRY 

SC #MAKE_KNOWN_CALL 
RET 

END MAKE KNOWN 
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2ei4 


0014 7F0t> 
0016 9E08 
001S 


READ PROCEDURE 

9 


'r 

PARAMETERS: 



Rl.-SEGMENT # 


3i' 

^2:INSTANCE 

2r 

2*.'5, 

»* 2,* 3,5 3JS 3,C 3JS 5,5 3j|C 3i% 5|5 5,: 5J5 SjjS 5^ 3j|* 5,5 ^5 5^53^5 

V 2<5 2;' 

3;« 

RETURNS : 

2? 

3?: 

R0:SUCCESS CODE 

3i« 

2.: 

RR4:EVENTCOUNT 

"i* 


ENTRY 

sc ;fREAD_CALL 
RET 

END READ 


0018 


0018 7F0V 
001A 9E08 
001C 

001C 


001C 7F08 
001E 9S08 
0020 


0020 


0020 7F09 


SM_SWAP_IN PROCEDURE 

»•' PARAMETERS; ^ 

- Rl; SEGMENT ff - 

^ RETURNS; 

R0:SUCCSSS CODE - 

ENTRY 

SC #SM_SWAP IN_CAIL 
RET 

END SM_SWAP_IN 
SM_SWAP_OUT PROCEDURE 

^ PARAMETERS: 

- Rl;SEGMENT ^ - 

^ RETURNS : 

P0; SUCCESS CODE - 

ENTRY 

SC ;#SM_SWAP_OUT_CALL 

RET 

END SM_SWAP_OUT 

TERMINATE PROCEDURE 

^ PARAMETERS: =!' 

*•' Rl:SEGMENT tt - 

3is 9;c 3^ ?;c>^ ^ 

RETURNS; 

- P0:sueCESS CODE - 

i!C3i:7fj;f3f7filC3fiii:3i:3i:fi:ti:3f!i3ievWWWW J 

ENTRY 

SC #terminate call 
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01522 

0024 

0024 


0024 

0026 

0023 

002S 

0023 

002A 

002C 

002C 

0020 

002E 

0060 

0030 

0030 

0032 

0034 


9E0S T’ET’ 

END TERMINATE 

TICKET PROCEDURE 

f :i;c3;i3ic ^ 

- PARAMETERS: - 

Ri:SEGMENT ^ 

V W 5,5 S^J SjS J|i sp S,C ^ SJJ 5i5 5|i 5;55,5 5^ 5^5 5,5 

^ RETURNS: 

R0:SUCCESS CODE =5* 

RR4:TICKET VALUE 

5;c5^:;e5^5;c5^:^a;5 5p5ic5^:^5;ca^5?9;5 3i55ic5^5^5)c5;;5^5,c ? 

ENTRY 

7P0A SC #TICKET_CALL 

9E08 RET 

END TICKET 

VRITE PROCEDURE 

ENTRY 

7E0fi SC #WRITE_CAI1 

9E0e RET 

END WRITE 

WRITELN PROCEDURE 

ENTRY 

7F0C SC #WRITELN_CALL 

9E03 RET 

END WRITELN 

CRLF PROCEDURE 

ENTRY 

7F0D SC «CRLF_CALL 

9E08 RET 

END CRLF 
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APPENDIX E - BOOTSTRAP LOADER LISTINGS 


Z8000ASM H.02 

LOG OBJ CODE STMT SOURCE STATEMENT 

BOOTS TRAP_LOaDEP. MODULE 

SLISTON STTT 
CONSTANT 


; SYSTEM PARAMETERS 


NR CPU 

= 2 

NR VP 

= NR CPU’*‘4 

NR AVAIL VP 

= NR CPU^2 

MAX DBR NR 

= 10 

STACK SEG 

= 1 

STACK SEG SIZE 

= %100 

STACK BLOCK 

= STACK SEG SIZE/255 

I ,jc 7 OFFSETS IN STACK SEG ’s' ! 

STACK base 

= STACK SEG SIZE-%10 

STATUS REG BLOCK 

= STACK SEG SIZE-%10 

INTERRUPT FRAME 

= stack BASE-4 

INTERRUPT REG 

= INTERRUPT FRAME-34 

N S P 

= INT£RRUPT"RiG-2 

F C ¥ 

= STACK SEG SIZE-%E 

wsjtvw SYSTEM CONSTANTS \ 

ON 

= %FFFF 

OFF 

= 0 

READY 

= 1 

NIL 

= %FFFF 

INVALID 

= %EEEE 

KERNEL FCW 

= %5000 

AVAILABLE 

= 0 

ALLOCATED 

= %FF 

SC OFFSET 

= 12 


! 


TYPE 


MESSAGE ARRAY 
ADDRESS WORD 
MM_VP_ID WORD 
VP INDEX 
MSS_INDEX 


115 BYTE] 

INTEGER 

INTEGER 
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MSG TABLK RECORD 
L MSG 
SENDER 
NEXT MSG 


MESSAGE 
7P_INDEX 
MSG INDEX 


FILLER ARRAY [6, 


J 


WORD] 


^P_TA3LE RECORD 

[ DBR ADDRESS 

PR I WORE 

STATE WORD 


IDLE FLAG WORD 

PREEMPT 'WORD 

PHYS_PROCESSOR WORD 
NEXT_READY_VP 7P_INDEX 
MSG_LIST MSG_INDEX 

EXT_ID WORD 

FILL£R_1 ARRAY . 


WORDJ 


EXTERNAL 

GET_D£R ADDR PROCEDURE 

CREATE STACK PROCEDURE 


LIST_INSERT PROCEDURE 

ALLOCATE_MMU PROCEDURE 

UPDATE_MMU_IMAGE PROCEDURE 
MM_ALLOCATE PROCEDURE 

MM_ENTRT LABEL 

IDLE ENTRY LABEL 


PREEMPT_PET LABEL 

BOOTSTRAP ENTRY LABEL 


GATE_KEEPER_ENTRY LABEL 

NEXT_BLOCK WORD 

MM CPU_TBL ARRAY[NR CPU MM_VP IDJ 


VPT RECORD 

[ LOCK WORD 

RUNNING_LIST ARRAYLNR_CPU WORDJ 
READY_LIST ARRAY [NR_CPU WOEEJ 
FREE_LIST MSG INDlX 

VIRT_INT_VEC ARRAY[1, ADDRESSJ 
FILLER_2 WORD 

VP ARRAY [NR_VP, VP_TABLEJ 

MSG_0 ARRAY [NR_VP, MSG_TABLEJ 
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0t}00 

0002 


EXT_VP_LIST ARRAY[NR_AVAIL VP WORDJ 
NEXT_AVAIL_MMU ARRAY IMAX_DER][nR EYTEJ 

PHDS RECORD 

[PHYS CPU ID WORD 
IOG_CPU_rD INTEGER 
?P_NR WORD 

IDLE_VP VP_INDEXj 


INTERNAL 

^SECTION L0ADER_DATA 

! NOTE: THESE DECLARATIONS WILL NOT WORK 
IN A TRUE MULTIPROCESSOR ENVIRONMENT AS 

they are subject to a "call." they must 

BE DECLARED AS A SHARED GLOBAL DATABASE 
WITH "RACE" PROTECTION (E.G., LOCK). ! 

NEXT AVAIL_VP INTEGER 
NEXT"EXT VP INTEGER 
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SSECTICN LOADEH INT 
INTERNAL 

0000 BOOTSTHAF PROCEDURE 

’i' creates kernel processes and 

’i' INITIALIZES KERNEL DATAEAS£S . 

=!' INCLUDES INITIALIZATION OF 
’i' VIRTUAL PROCESSOR TABLE, "• 

- EXTERNAL 7P LIST, AND - 

images. ALLOCATES MMU IMAGE '*!' 
AND CREATES KERNEL DOMAIN ’i' 
^ STACK FOR KERNEL PROCESSES. •“ 


0000 4E05 
0002 0000’i' 
0004 FFFF 


0006 

4D05 

LD 

0008 

0002’!' 


000 A 

s. 

0002 

1 

000C 

4D05 

LD 

000E 

0004V 


0010 

0002 


0012 

4D08 

CLR 

0014 

0000V 


0016 

4D08 

CLR 

0018 

0000' 


001A 

4D08 

CLR 

0010 

0002' 



001E 7D15 


ENTRY 

! INITIALIZE PRDS AND MMU POINTER ! 

! NOTE: TEE FOLLOWING CONSTANTS ARE 
ONLY TO BE INITIALIZED ONCE. THIS 
WILL OCCUR DURING SISTEM INITIALIZATION! 
LD PRDS.PHYS CPU ID, #‘?FFFF 


! NOTE: LOGICAL CPU NUMBERS ARE ASSIGNED 
IN INCREMENTS OF 2 TO FACILITATE INDEXING 
(OFFSETS) INTO LISTS SUBSCRIPTED BY 
LOGICAL CPU NUMBER. ! 

PRDS.LOG CPU ID, #2 


ASSOCIATED WITH PHYSICAL CPU. ! 
PRDS.VP NR, #2 


NEXT_BLOCK 
NEXT_AVAIL_7P 
NEXT EXT VP 


I ESTABLISH GATS KEEPER AS SYSTEM CALL 
TRAP HANDLER ! 

! GET BASE OF PROGRAM STATUS AREA ! 
LDCTL Rl, PSAP 


0020 0101 
0022 000C 

0024 0D15 
0026 5000 


! ADD system CALL OFFSET TO PSA BASS ADDR ! 
ADD Rl, #SC_OFFS£T 

I STORE KERNEL FCW IN PSA ! 

LD ORl, #KSfiNEL_FCW 
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! ST0R3 ADDRESS 0? 5ATE KEEPER IN PROGRAM 




STATUS 

AREA AS SYSTEM TRAP HANDLER ! 

0028 

A911 

INO 

R1 , #2 

002A 

0D15 

LD 

GRl, #GATS_KSEPER_SNTRr 

0020 

0000’!' 



002E 

8D18 

OLP 

HI ! NEXT_AVAIL_MMD INDEX ! 



! INITIALIZE ALL MMU IMAGES AS AVAILABLE 



SET_MMU_MAP 

« 



DO 


0030 

4015 

LDE 

NEXT_AVAIL_MMU(R1), #AVAILA£LE 

0032 

0000’!' 



0034 

0000 



0036 

A910 

INO 

Rl, #1 



! OHEOK FOR END OF TADLE ! 

0038 

0E01 

OP 

Rl, ffMAX_DBR_NR 

003A 

000A 



0030 

5E0E 

IF EO 

THEN EXIT from SET_MMU_MAP FI 

003E 

0044' 



0040 

5E0e 



0042 

0046' 



0044 

E8F5 

OD 




! OREATE 

MEMORI MANAGER PROOESS ! 

0046 

2103 

LD 

R3, #STAOK_BLOOK 

0048 

0001 





! ALLOOATE AND INITIALIZE KERNEL 



DOMAIN 

STAGE SEGMENT ! 

004A 

5E00 

OALL 

MM_ALLOGATE !R3: # OF SLOGKS 

0040 

0000’!' 






RETURNS 




R2: START ACER' 

004E 

A121 

LD 

Rl, R2 

0050 

2103 

LD 

R3, #KERNSL_FGW 

0052 

5000 



0054 

7604 

LDA 

R4, MM_SNTRY 

0056 

0000*!* 



0058 

6105 

LD 

R5, %FFFF !NSP! 

005A 

FFFF 



0050 

7606 

LDA 

R6, PREEMPT_RET 

005E 

0000^ 



0060 

93F1 

PUSH 

GR15, Rl !SAVE STAGE ADIR! 

0062 

030F 

SUB 

R15, #8 

0064 

0008 



0066 

10F9 

LDM 

GR15, R3, ?i4 

0068 

0303 



006A 

A1F0 

LD 

R0, R15 


! NOTE: ARGLIST POR CREATE_STACK INCIUDES 
KERNEL_FCW, INITIAL IC, NSP, AND INITIAL 



RETURN POINT. ! 


00t>C 

5F00 

CALL 

CREATE_STACK ! (R0: ARGUMENT PTR 

006E 

0000*^ 


Rl: TCP OF STACK 
R2-R14: INITIAL 
REG.STATES ! 

0070 

010F 

ADD 

Rib, «8 lOVERLAY ARGUMENTS! 

0072 

0009 





! ALLOCATE ^^MU IMAGE ! 

0074 

5F00 

CALL 

ALLOCATS_MMU !RETURNS: 

0076 

0000’?' 


(H0: LBR #) ! 

0078 

2101 

LD 

Rl, #STACK_SSG ! SEGMENT NO. ! 

007A 

0001 



007C 

97F2 

POP 

R2, 0R15 !GET STACK ADER! 

007E 

2103 

LD 

R3, f?0 ! WRITE attribute ! 

0080 

0000 





! SPECIFY NUMBER OF BLOCKS. COUNT STARTS 



FROM 

ZERO. (I.E. ,i SLOCK=0, 2=1, ETC.)! 

0082 

2104 

LD 

R4, #stack_block-i 

0084 

0000 

! SAVE 

DBR # ! 

0086 

93F0 

PUSH 

0R15, R0 




! CREATE 

MMU ENTRY FOR MM STACK 

SEGMENT ! 

0088 

5Fe0 

CALL 

UPDATE MMU IMAGE !(R0: DBR « 

00eA 

0000» 


Rl: 

SEGMENT 




R2: 

SEG ADDRESS 




R3: 

SEG ATTRIBU 




R4: 

SEG LIMITS) 



! RESTORE 

DBR n ! 


008C 

97F0 

POP 

R0, ORlb 




! GET ADDRESS OF MMU IMAGE ! 


008E 

5F00 

CALL 

GET_DBR_ADDR ! (R0: 

DBR s) 

0090 

0000’i' 







RETURNS: 




(Rl : 

DRR ADDRESS 



! PREPARE 

VP TABLE ENTRIES FOR 

MM ! 

0092 

2102 

LD 

R2, #2 ! PRIORITY 

j 

0094 

0002 




0096 

2105 

LD 

R5, #OFF ! PREEMPT 

I 

0098 

0000 




009A 

2106 

LD 

R6, #OFF ! KERNEL PROCESS ! 

009C 

0000 

! UPDATE 

VPT ! 


009E 

5F00 

CALL 

UPDATE_VP_TABLS !(Rl 

: DBR 

00A0 

01CA' 







R2: 

PRIORITr 
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Rb: PESEr^PT FLAG 
R6: EXT_VP FLAG) 
RETURNS: 

R9: VP_ID ! 

! INITIALIZE MM_CPU_T£L IN DISTRIFUTED MEriORY 
MANAGER WITH VP ID OF MM PROCESS J 
! GET LOGICAL CPU # ! 


00A2 

bl0A 

LD R10, PRDS.LOG CPU ID 

00A4 

0002’!' 



00A6 

6FA9 

LD 

MM_CPU_T£L(R10), R9 

00A8 

0000V 

! create 

IDLE PROCESS ! 

00AA 

2103 

LD 

R3, #STACK_BIOCK 

00AC 

0001 



00AB 

5F00 

CALL 

MM_ALLOCATE !R3: a OF BLOCKS 

0050 

0000’!' 






RETURNS 

R2: START ADDR! 

00R2 

A121 

LD 

R1 , R2 

00B4 

2103 

LD 

R3, #EERNSL_FCW 

00E6 

5000 



00R8 

7604 

LDA 

R4, IDLS_SNTRY 

00SA 

0000V 



00BC 

2105 

LD 

R5, #‘SFFFF !NSP! 

e0BE 

FFFF 



00C0 

7606 

LDA 

R6, PRESMPT_RET 

00C2 

0000’!' 



00C4 

93F1 

PUSH 

OR 15, R1 '.SAVE STACK ADDR! 

00C6 

030F 

SUB 

R15, #8 

00C8 

0008 



00CA 

1CF9 

LDM 

0R15, R3, #4 

00CC 

0303 



00CE 

A1F0 

LD 

R0, R15 



! INITIALIZE IDLE STACK VALUES ! 

00D0 

5F00 

CALL 

CREATE_STACK ! (R0; ARGUMENT FTT’ 

0eD2 

0000’" 






R1 : TOP 01 STACK 
R2-R14: INITIAL 
REG. STATES ' 

00D4 

010F 

ADD 

R15, #8 'OVERLAY ARGUMENTS! 

00D6 

0008 





? ALLOCATE MMU IMAGE FOR IDLE PROCESS ! 

00D8 

5F00 

CALL 

ALLOCATE_MMU ! RETURNS R0:D3R !f 

00DA 

0000V 





! PREPARE 

IDLE PROCESS MMU ENTRIES ! 

00DC 

2101 

LD 

Rl, #STACK_SEG ! SEG # ! 

00DE 

0001 



00E0 

97F2 

POP 

R2, 0R15 !GET STACK ADDR! 
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muz 

2103 

LD 

R3, #0 

! a’RITE attribute ! 

00E4 

0000 




00E6 

2104 

LD 

R4, #STACK_BLOCK 

-1 ! BLOCK LI'^ITS ! 

00Ee 

0000 






! SAVE DRR n ! 


00EA 

93F0 

PUSH 

9R15, R0 




! create 

IMAGE ENTR"^ ! 


00EC 

5F00 

CALL 

DPDATEj'1MU_lMAGE 

! (31: SEGMENT a 

e0EE 

0000=^ 



R2: SEG ADDRESS 

R3: SEG ATTRIBUTES 
R4: SEG LIMITS ) ! 



! RESTORE 

DER # ! 


00F0 

97F0 

POP 

R0, yR15 




! GET r^MU 

ADDRESS ! 


00F2 

5F00 

CALL 

GET_DBR_ADDR ! 

(R0: LBR #) 

00F4 

0000 V 



RETURNS 

(Rl; DBR ADDRESS) ! 



! PREPARE 

VPT ENTRIES FOR 

IDLE PROCESS ! 

00F6 

2102 

LD 

R2, #0 

! PRIORITY ! 

00F8 

0000 




00FA 

2105 

LD 

H5, #?OFF 

! PREEMPT ! 

00FC 

0000 




00FE 

2106 

LD 

E6, ftOTI 

! KERNEL PROC ! 

0100 

0000 

! CREATE 

VPT ENTRIES ! 


0102 

5F00 

CALL 

update_vp_table 

!(El: DSR 

0104 

01CA' 





R2: P5ICP.ITI 
R4: lELfi.ILAG 
R5: PREE^'FT 
R6: EXT_VP FLaG^ 
RETURNS: 

R9; VP ID ! 

! ENTER VP ID OF IDLE PROCESS IN FRDS ! 


0106 

6F09 

LD 

PRDS.IDLE VP, R9 


0108 

0008 







{ 

INITIALIZE 

IDLE VP'S ! 


010A 

2102 

LD 

R2, 

#1 ! 

PRIORITY ! 

010C 

0001 





010E 

2105 

LD 

Rb, 

#ON ! 

PREEMPT ! 

0110 

FFFF 





0112 

2106 

LD 

Re, 

#ON ! 

NON-KERNEL 

0114 

FFFF 





0116 

6100 

LD 

R0 , 

PRDS.VP_NR 


0118 

0004^ 







f 

INITIALIZE 

VP VALUES ! 



1S4 
























DO 


011A 

5F00 

CALL 

UPDATE_VP_TA3LS !(R1: EBR 

011C 

01CA' 


R2: PP.IORITI 

R4: IDLE FLAG 

R5: PREEMPT 

R6: EXT VP FLAG) 
RETURNS: 

R9: VP ID ! 

011£ 

A£00 

DEC 

R0, #1 

0120 

0B00 

CP 

R0, 

0122 

0000 



0124 

5E0S 

IF EC 

’ALL VP'S INITIALIZED! THEN 

0126 

012C' 



0128 

5E08 

EXI 

rp 

i. 

012A 

012E' 

FI 


012C 

E8F6 

OD 




! INITILIZE VPT HEADER ! 

! GET LOGICAL CPU NUMBER ! 

012E 

6102 

LD 

R2, PRDS.LOG_CPU_ID 

0130 

0002==* 



0132 

4D05 

LD 

VPT.LOCK, JiOFF 

0134 

0000>i‘ 



0136 

0000 



0138 

4D25 

LD 

VPT.RUNNING_LIST{R2) , ;*NIL 

013A 

0002’!' 



013C 

FFFF 



013E 

4D25 

LB 

VPT.HEADY_LIST(R2) , ??NIL 

0140 

0006’!' 



0142 

FFFF 



0144 

4D0e 

CLR 

VPT.FRSE_LIST !HEAD CF MSG LIST! 

0146 

000A=^ 




1 

THREAD VP 

'S BY PRIORITY AND SET STATES TO READY 

0148 

6D28 

CLR 

R2 ISTART WITH VP #1! 



THREAD: 




DO 


014 A 

610D 

LD 

R13, PRDS.LOG_CPU_ID 

014C 

0002’!' 



014E 

7bD3 

LDA 

R3,VPT.READT_LIST(R13) 

0150 

0006=* 



0152 

7604 

LDA 

R4,VPT.VP.NEXT_READY_VP 

0154 

001C’!' 



0156 

7605 

LDA 

R5,VFT.VP.PRI 

0158 

0012’" 



015A 

7606 

LDA 

R6,VPT.VP.STATE 

015C 

0014’" 



015E 

2107 

LD 

R7,#RFADY 
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0160 

0001 

! SAVE 

OBJ ID ! 

0162 

93F2 

PUSH 

0R15. R2 

0164 

5F00 

CALL 

LIST INSERT !R2: OBJ ID 

0166 

0000V 




R3: 

LIST HEAD 

PTR ADDR 

R4: 

NEXT OBJ 

PTR 

R5; 

PRIORITY_ 

PTR 

?.6: 

STATE PTP. 


R7: 

STATE ! 



! RJiiSTORJ!; OBJ ID ! 


0166 

97F2 

POP 

R2, yR15 

ei6A 

016C 

0102 

0020 

ADD 

R2, #SIZEOF VP_TABL£ 

016E 

0170 

0E02 

0100 

CP 

P2, ??(NR_VP - (SIZEOF V?_TABLE 

0172 

0174 

0176 

0178 

5E0E 
017A' 
5E08 
017C ' 

IF EO 

TEEN EXIT FROM THREAD FI 

017a 

E8E7 

OD 



! INITIALIZE VP MESSAGE LIST ! 

! NOTE; ONLY THE THREAD FOR THE MESSAGE 
LIST NEED BE CREATED AS ALL MESSAGES 
ARE INITIALLY AVAILABLE FOR USI. THE 
INITIAL MESSAGE VALUES WERE CREATED 
FOR CLARITY ONLY TO SHOW THAT THE 
MESSAGES HAVE NO USABLE INITIAL VALUE! 
017C 8D1S CLR R1 


MSG LST_INIT; 

"l NOTE: R1 REPRESENTS CURRENT ENTRY IN 

MSG LIST, R2 REPRESENTS CURRENT POSITION 
IN MSG_LIST entry, AND ^'6 REPRESENTS 
NEXT ENTRY IN MSG LIST. ! 




DO 



017E 

A112 

LD 

R2, 

R1 

0180 

A123 

LD 

R3, 

R2 

0182 

0103 

ADD 

R3, 

#SIZEOF MESSAGE 

0184 

0010 

FILL MS 

G; 




DO 



0186 

4D25 

LD 

VPT 

.MSG_C.MSG(H2), #INVALID 

0188 

0110>i‘ 




018A 

EEEE 




018C 

A921 

INC 

R2, 

#2 

0 iaE 

8B32 

CP 

R2, 

R3 

0190 

5E0E 

IF EO 

THEN 

EXIT FROM FILL MSG FI 

0192 

0198 ' 




0194 

5E08 



































eiye 
0198 
019A 
019C 
019S 
01A0 
01A2 
01A4 
eiA6 
01 AS 

01AA 

01AC 

01AE 

01B0 

01B2 

01S4 

01B6 

eiue 

01BA 

01BC 

01BE 

01C0 


01C2 

01C4 


01C6 

01C8 

01CA 


019A ' 
E6F5 

OD 


4Dlb 

LD 

7PT.MSG_0.SSNDER(R1) , #NIL 

0l20’i‘ 



FFPF 

A112 

LD 

R2, R1 

0101 

ADD 

Hi, ffSIZEOF MSG_TAi3LE 

0020 

0E01 

CP 

Rl, #SIZEOF MSG_TABLE’'NR_VP 

0100 

5E0E 

IF EC 
THEN 


01BC ' 
4D25 

LD 

VPT.MSG_0.NSXT_^SG(R2) , #NII 

0122’^ 

FFFF 

5E08 

EXIT 

FROM MSG_LST_INiT 

01C2' 

5E08 

ELSE 


0100' 

6F21 

LD 

VPT.MSG_0.N£XT_MSG(R2), Rl 

0122=^ 



E8DE 

FI 

OD 



! GST LOGICAL CPU # FOR USE 


B^ ITC 

GETWORE. ! 

510D 

LD 

R13, PRDS.LOG CPU ID 

0002=^ 

! BOOTSTRAP COMPLETE ! 


! START 

S'^STEM EXECUTION AT PREEMPT ENTRY 


! POINT 

IN ITC GETVORK PROCEDURE ! 

5E08 

JP 

BOOTSTRAP ENTRY 

0000Sr 




END BOOTSTRAP 
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01CA UPDATE VP TABLE PHOCEDUHE 

I 3;5:^3^3;sa;s;4c:;t:t:3;{:5C;?3!ca;<ajC3iSi!ca;«3jc;p;?ajsv3;s5SCa;s3;s3;s;;c5;«;ff:5sa^ 


?je 

INITIALIZES VPT ENTRIES 


^ #1% ^1% ^ ^ ^ 

•i« 3,* »,% - 

»• '♦» *»• 


REGISTER USE; 


ajt 

59c 

PARAMETERS; 


3 tC 


Rl: DBR ADDRESS 



ajc 

R2: PRIORITY 


¥ 

3 ;« 

R5; PREEMPT FLAG 


ai« 

V 

R8; EXTERNAL VP 

FLAG 


5? 

RETURNS; 



>;« 

R9; ASSIGNED VP 

ID 

a? 


LOCAL VARIABLES; 


ai» 

a;* 

R7; LOGICAL CPU 

tt 

J? 


R8; EXT VP LIST 

OFFSET 

a'.c 

a? 

R9; VPT OFFSET 


a? 


5jcj;sa;s3;C3;sajc3i«a;ssiff^s?3;sa;sV5!6=r3;s3;sa;5a;sa;s3;5a;s>;s>;s>;s3;s3?^a;sa;«3;s t 


ENTRY 

! GST OFFSET IN VPT FOR NEXT ENTRI ! 


eiCA 

6109 

LD 

R9, NEXT_AVAIL_VP 

01 CC 

0000 ' 



01 CE 

6F91 

LD 

V?T.VP.DBR(R9), Rl 

eiD0 

0010^^ 



01D2 

6F92 

LD 

VPT.VP'.PRI (R9) , R2 

01D4 

0012^ 



01D6 

6F96 

LD 

VPT.VP.IDLE_FLAG(R9). R6 

01D8 

0016’^ 



01DA 

6F95 

LD 

VPT.VP.PREEMPT(R9), R5 

01DC 

0018» 



01DE 

6107 

LD 

R7, PRDS.LCG_CPU_ID 

01E0 

0002’s' 



01E2 

6F97 

LD 

VPT.VP.PEYS_PROCESSOR(R9U R7 

01E4 

001A’^ 



01E6 

4D95 

LD 

VPT.VP.NEXT_P.EADT_V?(R9) , 4?NIL 

01 Ee 

001C’^ 



01EA 

FFFF 



01SC 

4D95 

LD 

VPT.VP.MSG_LIST(R9), #NII 

eiEE 

001E=» 



01F0 

FFFF 

! CHECK 

EXTERNAL VP FLAG 1 

01F2 

0B06 

CP 

R6, #ON 

01F4 

FFFF 

IF EO 

!EXTERNAL VP! 

01F6 

bE0E 

TEEN 

! VP IS TC VISIBLE ! 

01F8 

0210' 



01FA 

6108 

LD 

RS, NEXT_EXT_VP 

01FC 

0002' 





! INSERT ENTRY IN EXTERNAL VP LIST ! 

01FE 

6F89 

LD 

EXT_VP_LlST(Re), R9 


188 





0ki00 

0000’^ 



0202 

6F9e 

LD 

VPT.VP.EXT_ID(R9U Rb 

0204 

0020=^ 



0205 

A981 

INC 

Re, #2 

0208 

6F08 

LD 

NSXT_EXT_?P, R8 

020A 

0002' 



020 C 

5E08 

ELSE !VP BOUND TO KERNEL PROCESS 

020E 

0216 ' 



0210 

4D05 

LD 

VPT. VP.EXT_ID, JSNIL 

0212 

0020’i‘ 



0214 

FFFF 

FI 


0216 

A19A 

LD 

R10, R9 

0218 

010A 

ADD 

R10, #SIZEOF ?P_TABLE 

021A 

0020 



021C 

6F0A 

LD 

NEXT_AVAIL_VP, R10 

021E 

0000' 



0220 

9E0e 

RET 


0222 


END UPDATE 

7P TABLE 


END 

bootstrap' 

_loader 
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APPENDIX I - LIPRARY FUNCTION LISTINGS 


Z6000ASM 

LOG OBw^ CODE STMT SOURCE STATEMENT 


LIRRAR’^ function MODULE 


SLISTON $TTY 

CONSTANT 
KERNEL_FCW 
STACK_SSG_SIZE 
STACK_BASE 
STATUS_REG_ELOCK 
INTERRUPT FRAME 
INTERRUPT^REG 
N_S_P 
NIL 


= '^5000 
= '^100 

= STACK SEG_SIZE-%10 
= STACK~SEG_SIZE-;&10 
= STACK_EASS-4 
= INTERRUPT_FRAME-24 
= INTERRUPT_REG-2 
= ^FFFF 
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^SECTION LIB_?POC 
GLOBAL 

eeoe' LIST_ INSERT PROCEDURE 

INSERTS OBJECTS INTO A LIST 
BY ORDER OF PRIORITY AND SETS ^ 


35< 

ITS STATS 

5i« 



a? 

REGISTER USE: 


sp 

PARAMETERS: 

V 


R2: OBJECT ID 

a,« 


R3: HEAD OF LIST PTR ADDR 


aj; 

R4: NEXT OBJ PTR ADDR 

a? 

a? 

R5: PRIORITY PTR ADDR 


5je 

R6: STATE PTR ADDR 

ajt 


R7: OBJECT STATS 

5J5 

a? 

LOCAL VARIABLES: 

V 

5JC 

R6: READ OF LIST PTR 

5? 

5? 

R9: NEXT OBJ PTR" 


aji 

R10: CURRENT OBJ PRIORITY 

V 


Rll: NEXT OBJ PRIORITY 

a? 




0000 2138 
0002 0E08 
0004 FFFF 
0006 5E0E 
0008 0018' 


ENTRY 

! GET FIRST OBJECT IN LIST ! 
LD R8, PR3 

CP R8, #NIL 

IF EO 'LIST IS EMPTY! THEN 


! PLACE OBJ AT HEAD OF LIST ! 


000A 

2F32 

LD 

0R3, R2 


000C 

000E 

7449 

0200 

LDA 

R9, R4(R2) 


0010 

0012 

0014 

0016 

0D95 

FFFF 

5E08 

005A' 

ID 

ELSE 

! compare OBJ 

PR9. BNII 

PRI WITH LIST HEAD PRI ! 

0018 

001A 

715A 

0200 

LD 

R10, R5(R2) !OBJ 

PRI ! 

001C 

001E 

715B 

0800 

LD 

Rll, R5(P8) !HSAD 

PRI ! 

0020 

8BBA 

CP 

R10, Rll 


0022 

0024 

5E02 

0030' 

IF GT !OBJ PRI>HEaD PR I! TEEN 


0026 

2F32 

LD 

0R3, R2 !PUT AT 

FRONT! 

0028 

ee2A 

7348 

0200 

LD 

R4(R2) , R8 


002C 

5E08 

ELSE ! INSERT 

IN BODY OF LIST ! 



191 



0JW 






































002E 005A 


SEARCH LIST: 
DO" 


0030 

0B08 

CP 

R8, ifNiL 

0032 

FEEF 



0034 

5E0E 

IE EC 

!END OF LIST! THEN 

0036 

003C ' 



0038 

5E08 

EXIT 

FROt^ SEARCH_LIST 

0e3A 

0052' 

FI 


003C 

715B 

LD 

Rll, R5(R8) 

003E 

0800 



0040 

8BBA 

CP 

R10, Rll 

0042 

5E02 

IF GT 

!CURRENT PRI^NEXT 

0044 

004A' 



0046 

5E08 

EXIT 

FROM SEARCfi_LIST 

0048 

0052' 

FI 




! GET 

NEXT OBJ ! 

004A 

MB9 

LD 

R9, R6 

004C 

7148 

LD 

R8, R4{R9) 

004E 

0900 



0060 

ESEE 

OD ! 

END SEARCH_LIST ! 



! INSERT IN LIST ! 

0052 

7348 

LD 

R4(R2), Re 

0054 

0200 



0056 

7342 

LD 

R4(R9), R2 

0058 

0900 

FI 




FI 




! SET OSJ 

ECT'S STATE ! 

005A 

7367 

LD 

R6(R2), R7 

005C 

0200 



005E 

9E08 

RET 



0050 


END LIST INSERT 


FP.I 


192 


















0060 


CHEATii_STACK PROCEDURE 

f SiS 3|» 3p ^ Sp 7ji 3^ 3^ ^ Sfi ^ ^ V V ^ ^ V ^ V 2^ 

’i' INITIALIZES KERNEL STACK 

- segment fop. processes 

2|C SfiSjfi 2^S 2|C SjC 2iC 2|fS «^C «i* S^* *1* *i^ 'i* 


3? 


3? 


3i« 

3? 


REGISTER USE: 

PARAMETERS: 

R0: ARGUMENT POINTER 
(INCLUDES:rCW,IC,NSP, AND 
RETURN POINT. SEE LOCAL 
VARIABLES BELOW.) 

Rl: TOP OF STACK 
R2-R14: INITIAL REGISTER 
STATES. (NOTE; IN DEMO, 


3»S 

3JC 

3? 

NO^ 


^ SPECIFIC INITIAL HEGlSTEfi ^ 

^ VALUES ARE SET , EXCEPT 

- (USER ID) FOR USER PRO- - 

^ CESSES.) ^ 

2;c s^c sgs s^e 3^ 2^ 3^ 9(: 3^ s;: 2^a(C3^ 2iC2^ 2is 2^ »ic 2^ ;;c 3^ 3ic 

- LOCAL VARIABLES 



(FROM 

arguments stored ON 

3Jt 

3;s 

STACK. ) 


3^ 


R3; 

FCW 


3? 

3? 

R4: 

PROCESS 

ENTRY POINT(IC) 



R5; 

NSP 


3? 

3*5 

R6: 

PREEMPT 

RETURN POINT 

S|« 




ENTR”^ 


0060 

93F0 

PUSH 

GR16, R0 !SAVB ARGUMENT PT?! 

0062 

ADF0 

EX 

R0, R15 !SAVE SP1 

0064 

341F 

LDA 

R15, R1(#INTSRRUPT_REG) 

0066 

00CA 



0068 

1CF9 

LDM 

ORlb, Rl, **16 ! INITIAL REG. VALU 

006A 

010F 

! NOTE; 

ONLY REGISTERS R2-R14 MAT CONTAIN 



INITIALIZATION VALUES ! 

006C 

A10F 

ID 

R15, R0 'RESTORE SP! 

006E 

97F0 

POP 

R0, 0R15 ! RESTORE ARGUMENT PTR! 

0070 

AIFE 

ID 

R14, R15 iSAVE CALLER RETURN POIN' 

0072 

A10F 

LD 

R15, R0 !GET ARGUMENT PTR! 

0074 

ICFI 

LDM 

R3, 0R15, ^4 !LOAD ARGUMENTS! 

0076 

0303 



0078 

341F 

LDA 

Rib, R1(#INTERRUPT_FEAME) 

007 A 

00EC 



007C 

1CF9 

LDM 

0Rlb, R3, #2 !INIT IRST FRAME! 

007E 

0301 



0080 

341F 

LDA 

R15, R1(»N_S_P) 

0082 

00C8 



0084 

2FF5 

LD 

0R15, R5 !SST NSP! 

0086 

030F 

SUB 

R15, #2 




193 





0088 

0002 



0e8A 

2Fr6 

LD 

OR 15, R6 ! PREEMPT RET POINT! 

008C 

3418 

LDA 

R8, R1(#STACK_BASE) 

008E 

00F0 





! INITIALIZE STATUS RSGISTS? FLOCK ! 

0090 

2100 

LI) 

R0, #KSRNEL_FC'v 

0092 

5000 



0094 

1C89 

LDM 

0R8, R15, HZ !SAVS SP FC'*'! 

0096 

0F01 



0098 

AlEF 

LD 

R15, R14 I RESTORE RETURN POINT 

009A 

9E08 

RET 


009C 


END CREATE STACK 


END 

LIBEARr 

FUNCTION 
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appendh g - inner traffic contolier listings 


Zbee'0ASM ^.02 

IOC OBJ CODE STMT SOURCE STATEMENT 

INNER_TRAF?IC_CONTROL MODULE 
^LISTON $TTY 


!--l. GETWORK; 

A. NORMAL ENTRY DOES NOT SAVE REGISTERS. 

( THIS IS A FUNCTION OF THi GATEKEEPER ). 

B. R14 IS AN INPUT PARAMETER TO GETWOP.K THAT 
SIMULATES INFO THAT WILL EVENTUALLY BE ON 
THE MMU HARDWARE. THIS REGISTER MUST EE 
ESTABLISHED AS A DBR BY ANY PROCEDURE 
INVOKING GETWCRK. 

C. THE PREEMPT INTERRUPT ENTRY HANDLER DOES 
NOT USE THE GATEKEEPER AND MUST PERFORM 
FUNCTIONS NORMALLY ACCOMPLISHED BY IT 
PRIOR TO NORMAL ENTRY AND EXIT. 

( SAVE/RESTORE: REGS, NSP; UNLOCK VPT, TEST INT) 


2. GENERAL: 

A. ALL VIOLATIONS OF VIRTUAL MACHINE INSTRUCTIONS 
APE CONSIDERED ERROR CONDITIONS AND WILL RETURN 
SYSTEM TO THE MONITOR WITH AN ERROR CODE IN R0 
AND THE PC VALUE IN R1. 

B. ITC PROCEDURES CALLING GETWORK PASS DBR 
(REGISTER R14) AND LOGICAL CPU NUMBER 
(REGISTER R13) AS INPUT PARAMETERS. 

(INCLUDES: SIGNAL, WAIT, SWAP VDrP. 

PHYS PREEMPT HANDLER, AND IDLE). ! 


CONSTANT 

T n* ^ V SjfS ^ 5,C 

U L : = 

M_L_SM := 

M L ER := 

R~lIe := 

M_L_0 := 

SNA 

V~i“e := 

M U“ : = 


^ ERROR CODES » 

e ! UNAUTHORIZED LOCK ! 

1 ! MESSAGE LIST EMPTY ! 

2 ! MESSAGE LIST ERROR 1 

3 ! READY LIST EMPTY ! 

4 ! MESSAGE LIST OVERFLOW 

5 ! SWAP NOT ALLOWED ! 

6 ! VP INDEX ERROR ! 

7 ! MMU UNAVAILABLE ! 


; 


NR_SDR 
NR_CPU 
NR VP 


SYSTEM PARAMETERS 

:= 64 !LONG WORDS! 
:= 2 

:= NR CPU’!'4 


NR AVAIL VP 


NR CPU’!'2 
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MAX DBF. NR 

10 !PER 

CPU! 

STACK SEG := 

1 



PRDS SEG 

: = 

0 



STACK_SEG_SIZE := 

%100 



I OFFSETS IN 

STACK 

SEG 


STACK BASE := 

STACK 

SEG 

SIZE-%i0 

STATUS REG BLOCK:= 

STACK 

SEG 

“SIZE-^10 

INTERRUPT FRAME := 

stack' 

BASE-4 

INTERRUPT REG := 

INTERRUPT 

_FEAME-34 

N S P 

: = 

interrupt 

R E G — 2 

F_C_W 

: = 

stack 

_SEG 

'SIZE-%E 

ON 

= %FFFF 




OFF 

= 0 




RUNNING 

= 0 




READY 

= 1 




WAITING 

= 2 




NIL 

= ^FFFF 




INVALID 

= ^EEEE 




MONITOR 

:= XA900 


! H3UG ENTRY 

KERNEL FCW := ^5000 



AVAILABLE := 0 




ALLOCATED := %FF 





TYPS 

MESSAGE AREAY [16 
ADDRESS WORD 


£YTE] 


VP_INDEX 
MSG INDEX 


INTEGER 

INTEGER 


SEG_DESC_REG RECORD 

L 


J 


PASE ADDRESS 

ATTRIBUTES BYTE 

LIMITS BYTE 


MMU 


ARRAY [NR SDR SSG DESC REGJ 


MSG_TABLE RECORD 
C MSG 
SENDER 
NEXT MSG 
FILLER 


MESSAGE 
VP_INDEX 
MSG_IND£X 
ARRAY [6, 


*(ORrj 
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2! $50 45 


01510 


0000 


0A0e 

0A0A 


VP TABLE RECORD 
■ [ Difi ADDRESS 


PR I WORD 
STATE /^ORD 
IDLE_PLAG J^ORD 
PREEMPT WORD 


PHYS_PROCESSOR WORD 
NEXT READY VP VP_INDEX 
MSG_INDEX 
WORD 

ARRAY t?. WORE] 


'^SG_LIST 
SXT_ID 
FILLER 1 


EXTERNAL 

LIST INSERT 


PROCEDURE 


GLOBAL 

bootstrap_entrt label 

^SECTION 1TC_DATA 

VPT RECORD 

[ LOCK WORD 

RUNN1NG_LIST ARRAY[NR_CPU WORD] 
ready list array [NR CPU WORDJ 
FREE_riST MSG_INDEX 

V1RT_INT_VEC ARRAY[1, ADDRESS] 
FILLER_3 WORD 

VP ARRAY [NR VP, VP_TABLEJ 

MSG_0 ARRAY InR_VP. MSG_TAi;ISJ 

J 

EXT_VP LIST ARRAY[NR AVAIL VP WORDJ 


SSECTION MMU DATA 


MMU IMAGE RECORD 

■[ 

MMU_STHUCTURE ARRAY[MAX_DBR_NR MMUJ 

] 

NEXT_AVAIL_MMU ARRAYrMAX_DBR_NR BYTE] 

PRDS RECORD 

[PHYS_CPU_ID WORD 
LOG_CPU_ID INTEGER 
VP_NR WORD 

IDLE_VP VP_INDEXJ 
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^SECTION ITC_INT_PfiOC 
INTERNAL 

fc)000 GET'rfORS PROCEDURE 

SWAPS VIRTUAL PROCESSORS ’S' 
- ON PHYSICAL PROCESSOR. 

^ 3;c 3;c ^ ;iQC ;;c 3^ 3;c 3;c 3^ 3;c sje ^ ^ 3is 3;c a^c 3is 3;c ^ 3is s;; ^ V 


3JC 

PARAMETERS: 


V 

R13: 

LOGICAL CPU # 

S.' 


REGISTER USE: 

5? 


STATUS REGISTERS 


V 

R14: 

DER (SIMULATION) 



Rib; 

STACK POINTER 



local 

1 VARIABLES: 


5? 

Rl: 

READI VP (NEW) 



R2: 

CURRENT VP (OLD) 



R3; 

FLAG CONTROL WORD 



R4: 

STACK SEG BASE ADDR 

V 


Rb: 

STATUS REG BLOCK ADDR 


y?' 

R6: 

NORMAL STACK POINTER 

5? 




ENTRY 




! GET 

STACK BASE ! 

0000 

31E4 

LD 

R4, Rl4(ffSTACK_SEG’-4 ) 

0002 

0004 



0004 

3445 

LDA 

R5, R4(i^STATU5_REG_BL0CK ) 

0006 

00F0 

j V v 

SAVE SP ! 

0008 

2F5F 

LD 

0R5, R15 



J 2? V 

SAVE FCW V V ! 

000A 

7D32 

LDCTL 

R3, FCW 

000C 

3343 

LD 

R4(#F_C_W), R3 

000E 

00F2 




BOOTSTRAP 

ENTRY: ! GLOBAL LABEL ! 



! GET 

ready VP LIST ! 

0010 

61D1 

LD 

Rl, VFT.READY_LIST(R13) 

0012 

0006' 

SELECT 

VP: 



DO ! 

"until EIGIBLE ready VP FOUND ! 

0014 

4D11 

CP VPT.VP.IDLE FLAG(Rl), #ON 

0016 

0016' 



0018 

FFFF 



001A 

5E0E 

IF EC ! VP IS IDLE ! THEN 

001C 

0030' 



001E 

4D11 

CP 

VPT.VP.PREEMPT(Rl), «ON 

0020 

0018' 



0022 

FFFF 



0024 

5E0E 

IF 

EQ ! PREEMPT INTERRUPT IS ON ! 


THEN 
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0025 

002C ' 


0028 

e)£0S 

EXIT FROM SSLECT_VP 

002A 

003C ' 

FI 

002C 

5E0e 

ELSE ! VP NOT IDLE ! 

002E 

0034' 


0030 

5E0e 

EXIT FROM SELECT_VP 

0032 

003C' 

FI 

! GET NEXT READY VP ! 

0034 

6113 

LD E3, VPT.VP.NEXT_READI 

0036 

001C ' 


0038 

A131 

LD R1, R3 

003A 

E8EC 

OD 


! NOTE: THE READY_LIST WILL NEVER BE EMPTY SINCE 
THE IDLE VP, WHICH IS THE LOWEST PP.I VF, 

WILL NEVER BE REMOVED FROM THE LIST. 

IT WILL RUN ONLY IF ALL OTHER READ'’’ VP'S ARE 
IDLING OR IF THERE ARE NO OTHER VP'S ON 
THE READY_LIST. ONCE SCHEDULED, IT 
WILL HUN UNTIL RECEIVING A HDWE INTERRUPT. ! 

! NOTE: R14 IS USED AS DBR HERE. WHEN MMU 

IS AVAILABLE THIS SERIES OF SAVE AND LOAD 
INSTRUCTIONS WILL BE REPLACED BI SPECIAL I/O 
INSTRUCTIONS TO THE MMU. ! 

! PLACE NEW VP IN RUNNING STATE ! 


003C 

4D15 

LD 

VPT.VP.STATE(RI), ^RUNNING 

003E 

0014' 



0040 

0000 



0042 

6FD1 

LD 

VPT.RUNNING_LIST(R13) , R1 

0044 

0002' 

f ip 

- SWAP DBR - - ! 

0046 

611E 

LD 

R14, VPT.VP.DBR(R1) 

0048 

0010' 





! LOAD NEW VP SP ! 

0e4A 

31E4 

LD 

R4, R14(#STACK_SEG’^4) 

004C 

0004 



004E 

3445 

LDA 

R5, R4(«STATUS_REG_BLOCK) 

0050 

00F0 



0052 

215F 

LD 

R15, GR5 



f ip 

LOAD NSW FCW - ! 

0054 

3143 

LD 

E3, R4(#F_C_V) 

0056 

00F2 



0058 

7D3A 

LDCTL FCW, R3 

005A 

9E08 

RET 


005C 


end getwork 
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eeac 


fe;05C 61D2 
005E 0002' 


0060 6103 
0062 000A' 


3NTER_MSG_LIST PROCEEUHi:; 

»>* INSERTS POINTER TO MESSAGE 

FROM CURRENT_VP TO SIGNALED Vp’!' 
IN FIFO MSG_LIST ~ 

•? 5|% S|* ^|C #i« 3^ 3^ 3)* 5|S 3|* 3^ 3|* 3|« 3yC#|S 3|« 3|* 3|* 3|C 3^ 3|« Sfi 3^ 3|* ijS Jit 3|« 

REGISTER USE; ^ 

PARAMETERS: ^ 

- R8(R9);MSG (INPUT) 

’!* Rl; signaled VP (INPUT) ^ 

R13: LOGICAL~CPU NUMBER ^ 

- LOCAL VARIABLES: - 

’i' R2: CUF.RENT_VP 

R3: FIRST_FREE_MSG 

- R4: NEXT FREE MSG - 

’f R5: NE7T”0_MSG 

’i' R6; PRESENT_0_MSG ’i' 

3j|C 3|S 3^ 3|^3^ 3^ 3;e 3^« 3^* 3;^ 3^ 3^* ^ 3^ 3|^ ^ 3j« 3t«S|C 3|« 3^ ifi 3^« f 

ENTRY 

LD R2, VPT.RUNNING_LIST(R13) 


! GET FIRST MSG FROM FREE_LIST ! 
LD R3, VPT.FPEE LIST 


0064 

0066 

0068 

006A 

006C 

006E 

0070 

0072 

0074 

0076 


0E03 
FFFF 
5E0S 
0073' 
7601 
006C ' 
2100 
0004 
5F00 
A900 


0078 6134 
007A 0122' 
007C 6F04 
007E 000A' 

0080 763A 
0082 0110' 

0084 2107 
0086 0010 
0088 BASl 
008A 07A0 


I SJC V :)e :(« DJ^JJ^G ^ =P s? t 

CP R3, #NIL 
IF EO THEN 
IDA Rl, S 

ID R0, #M_L_0! MESSAGE LIST OVERFLOW ! 
CALL MONITOR 
FI 

! V V 2ND DEBUG v v r 

LD R4, VPT.MSG_0.NEXT_MSG(R3) 

LD VPT.FREE_LIST, R4 

! INSERT MESSAGE LIST INFORMATION ! 

LDA R10,VPT.MSG_C.MSG(R3) 

LD R7,#SIZE0F MESSAGE 

LDIRB OR10,GR8,R7 
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008C 

008E 


0090 

0092 

0094 

0096 

0098 

009A 

009C 

009E 

00A0 

00A2 


00A4 

00A6 

00A8 

00AA 

00AC 

00AE 


6E32^ 

0120 


6115 

001E' 

0E05 

FFEF 

5E0S 

00A4' 

6F13 

001E' 

5E08 

00EC' 


0B05 

FFFF 

5E0E 

00B0' 

5E08 

0038' 


LD VFT.MSG 0 .SENDER{R3 ) , R2 


! INSERT ^SG IN MSG_LIST ! 
LD R5, VPT.VR.MSG LIS?(Rl) 


CP R5, #NIL 

IF EO ! r^SG LIST IS EflPTI ! THFN 

! INSERT ^SG AT TOP OF LIST ! 

ID VPT.7P.MSG_LIST(R1), R3 

ELSE ! INSERT MSG IN LIST ! 
MSG_0_SEAECH: 

DO ! '^HILE NOT END OF LIST ! 

CP R5, ffNIL 

IF EO ! END OF LIST ! THEN 

EXIT FROM MSG_C_SEARCH 

FI 

! GET NEXT LINE ! 


00B0 

A156 

LD 

H6, 

00B2 

6165 

LD 

R5, 

0034 

0122 

✓ 


0036 

E8F6 

OD 

! INSERT 

MSG 

00B8 

6F63 

LD 

VPT. 

003 A 

0122 

✓ 

FI 


003C 

6F35 

LD 

VPT 

00BE 

0122 

✓ 


00C0 

9E08 

RET 


00C2 


END ENTER_MSG_LI 


VPT.MbG O.NEXT MSG(R3U P 
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20C2 


0eC2 61D2 
00C4 0002' 


GST_FIRST_MSG PROCEDURE 

- REMOVES MSG FROM MSG_IIST 
’i' AND PLACES ON FREE LIST. 

RETURNS SENDER'S MSG AND 

- VP_ID 

-REGISTER USE: ’i' 

PARAMETERS t 

R8(R9): MSG POINTER (INPUT'I 
R13: LOGICAL CPU NUMBER (INPUT)- 



Rl: 

SENDER VP (RETURNED) 

3!C 


LOCAL 

, VARIABLES 

3«5 


R2: 

CURRENT VP 

3|S 


R3: 

FIRST MSG 


3!e 

R4: 

NEXT MSG 

3!C 


R5: 

NEXT_FREE_MSG 



R6: 

PRESENT FREE MSG 

3? 


ENTR'^ 

LD R2, VFT.RUNMNG_LIST(R13^ 


! REMOVE FIRST MSG FROM MSG_LIST ! 
00C6 6123 LD E3, VPT.VP.MSG IIST(R2) 

00C8 001E' 


0-4JCA 

0B03 

00CC 

FFFF 

00CE 

5E0E 

oe'De 

00DE' 

00D2 

2100 

00D4 

0001 

00D6 

7601 

00D8 

00D6 ' 

00DA 

5F00 

00DC 

A900 


00DE 

00E0 

6134 

0122' 

LD 

00E2 

00E4 

6F24 

001E' 

LD 

00E6 

00E8 

6105 

000A' 

LD 

00EA 

00EC 

0B05 

FFFF 

CP 

00EE 

00F0 

5E0E 

0100' 

IF EO 


j V V V V debug 

CP R3, #NIL 
IF EO then 
LD R0, #M_L_EM 
LDA Rl, $ 

CALL MONITOR 


ifi Sfi 5,5 f 


! MSG LIST EMPTY 


FI 

I 5^ V 5? i^|yjD DEBUG '7 V ^ j 
R4, VPT.MSG_C .NSXT_MSG(R3) 

VPT.VP.MSG_LIST(R2) , ?.4 

! INSERT MESSAGE IN FREE LIST ! 
R5, VPT.FREE_LIST 

R5, #NIL 

! FREE LIST IS EMPTY ! TEEN 
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0eF2 

6F03 

LD 

00F4 

00eA' 


00F6 

4D35 

LD 

00F8 

0122' 


00FA 

FFFF 


00FC 

5E08 

ELSE 

00FE 

011C ' 

FREE C 
DO 

0100 

0E05 

CP 

0102 

FFFF 


0104 

5E0E 

IF 

0106 

010C' 


0108 

5E08 


010A 

0114' 

FI 

! 

LD 

010C 

A156 

010E 

6165 

LD 

0110 

0122' 


0112 

EeF6 

OD 


! INSJ!.iiT AT TOP OF LIST ! 

VPT.FRS3 LIST, R5 


VPT.r^SG_Q.NLXT_!^SG(R3 ) , f*NIL 
! INS3P.T IN LIST ! 


R5, )?NIL 

EO ! END OF LIST ! THEN 
EXIT FROM FREE 0 SEARCH 


R6, R5 

R5, VPT .MSG_C.NEXT_MSG(Re) 


! INSERT IN LIST ! 


0114 

0116 

6F63 

0122' 

LD 

VPT.MSG_O.NEXT_MSG(R6), R3 

0118 

011A 

6F35 

0122' 

LD 

VPT.MSG_0.NEXT_MSG(R3), R5 


FI 

! GET MESSAGE INFORMATION: 
(RETURNS Rl: SENDING 7P) ! 


011C 

6131 

LD 

Rl, VPT.MSG 

_0.SENDER(R3) 

011E 

0120' 




0120 

763A 

LDA 

R10.VPT.MSG 

_0.MSG(R3) 

0122 

0110' 




0124 

2107 

LD 

R7,^^S1ZE0F 

MESSAGE 

0126 

0010 




0128 

BAAl 

LDIRB 

OR8,OR10,R7 


012A 

0780 




012C 

9E08 

RET 



012E 


END GET 

FIRST MSG 



H03 























! ^ INNER TRAFFIC CONTROL ENTRY POINTS - - 


I 


0000 


0000 

0002 


0004 

0006 

0008 

000A 


! NOTE: AIL INTERRUPTS MUST BE MASKEE WHENEVER 
THE VPT IS LOCKED. THIS IS TO PREVENT AN 
EMBRACE FROM OCCURRING SHOULD AN INTERRUPT 
OCCUR WHILE THE VPT IS LOCKED. ! 

GLOBAL 

SSECTION ITC_GLB_PROC 

PP.EEMPT_RET LABEL 
KERNEL EXIT LABEL 

create2int_vec procedure 

creates entry in virtual int-** 

ERRUPT VECTOR WITH ADDRESS - 
’i' OF THE VIRTUAL INTERRUPT HAN-^- 
“S' DLER. 

2f« «|( 3iC 3 ^ 3i« «|* 2|C 4^ ^|« «|C ifi 3 ^ 3 ^ 3 ^ «|* 

^ PARAMETERS: 

R1 : virtual INTERRUPT # 

R2: interrupt HANDLER ADDR - 


1900 

0002 


6F12 

000c' 

9E0B 


ENTRY 

! COMPUTE OFFSET IN VIRTUAL 

interrupt vector ! 

MULT RR0, »SIZE0F ADDRESS 

! SAVE ADDRESS OF VIRTUAL INTERRUPT 
HANDLER IN INTERRUPT VECTOR ! 

LD VPT.VIRT_INT_VSC(R1) , P.2 

RET 

END create I NT VEC 
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eeeA 


00i)A 

000C 


000E 

0010 

0012 


GET DBH ADER PROCEDHRE 

CALCULATES DEH ADDRESS FROM - 
DBR NUMBER 

^ 9^ 3ie :gc ^ :(c:iic 3p 9^ 3^ 3;c:p 3^ 3^:;; 3p 3^ V ^ 9 


5? 

REGISTER USE: 



PARAMETERS : 



P.0: DBR 


K* 

RETURNS: 



Rl; DBR ADDRESS 



5!«Sit’ps?V>!c WJP’i'WJjesjs’PVS? VS!eS!t5^s?5r J 

ENTR^ 

! GET BASE ADDRESS OF MMU IMAGE ? 

7601 LDA Rl, MMU_IMAGE 

0000 ' 

! ADD DBR HANDLE (OFFSET) TO MMU EASE 
ADDRESS TO OBTAIN DBR ADDRESS ! 

8101 ADD Rl, R0 

9E08 RET 

END GET DBR ADDR 







































0feJl2 


0012 

0014 


0016 

0018 

001A 

001C 

001E 

0020 

0022 

0024 

0026 

0028 

002A 

002C 

002E 

0030 

0032 

0034 

0036 

0038 

003A 

003C 

003E 

0040 

0042 

0044 

0046 


ALLOCATE_MMU PROCEDURE 

ALLOCATES NEXT AVAILABLE MMU ^ 
IMAGE AND CREATES PRDS ENTRY 

>;c qc ^ 3;c 3(( 9^ ^ ;gc ;gc 9 ^ 9^ ;;c M V >;< ^ic i<< 9r ^ 


5? 

REGISTER USE; 



RETURNS ; 



R0; DBR # 


•if 

LOCAL VARIABLES; 

S|C 


Rl ; SEGMENT P 

ajc 


R2; PRDS ADDRESS 

a? 

a? 

R3; PRDS ATTRIBUTES 

V 

ajc 

R4; PRDS LIMITS 

ajK 


9}:9p9iC9^9;t9tc9i:9^:t:3iC3i<3^X«9^9;c:^9iC9i:9^9^9;::;c9;c9p9^:t«9;c9;:9^:p9tc9i: f 

ENTRY 

! GET NEXT AVAILABLE DBR # ! 

SD08 CLR P.0 

SD18 CLR R1 

1 NOTE; THE FOLLOWING IS A SAFE SECUENCE 
AS NEXT_AVAIL_'^MU AND MMU ARE CPU LOCAL! 
GET_DER; 

DO 

4C11 CPE next_avail_mmu(ri) , ^^AVAILABLE 

0A00' 

0000 

IF EO !MMU ENTRY IS AVAILABLE! 

5E0E THEN 

002E' 

4C15 LDB NEXT_AVAIL_MMU(R1) , #ALLOCATED 

0A00' 

FFFF 

5E08 EXIT PROM GST_DEP 

004A' 

5E08 ELSE !CURRENT ENTRY IS ALLOCATED! 

0048' 

A910 INC Rl, #1 

0100 ADD R0, #SIZEOF MMU 

0100 

j 9? 9^ V V DEBUG V V V I 
0E01 CP Rl, #MAX_DBR_NR 

000A 

5E0E IP EO THEN 

0048' 

2100 LD R0, #M_U !MMU UNAVAILABLE 

0007 

7601 LDa Rl, $ 

0040 ' 

5F00 CALL MONITOR 

A900 

FI 

; 3^ 3): v 


END DEBUG ^ v \ 





















0048 

E8E6 

1 

o 

004A 

2101 

LD 

004C 

004E 

0000 

7602 

LDA 

0050 

0052 

0A0A' 

2103 

LD 

0054 

0056 

0001 

2104 

LD 

0058 

0000 

! PRDS 


Rl, #PRDS_SE(; 
R2, PHDS 
R3, ! read 

R4, #{(SIZSOF 
LIMITS ! 


! SEGMENT NO. 
! PHDS ACPH 
ATTR ! 

PRDS)-l)/2£e 


; 

T 


! CREATE PRDS ENTRY IN MMU IMAGE ! 
0{^5A 5F00 CALL UPDATE_MMU_ I MAGE !(R1: 
00bC 0060' 

RH : 
RS: 
R4 : 

005E 9E08 RET 

0060 END allocate MMU 


SEGMENT ^ 

SEG ADDRE 
ATTHISUTS 
SEG LIMITS ) ! 
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00645 UPCATfi_MMU_lMAGE PROCEEURE 




CREATES SEGMENT DESCRIPTOR 
ENTRY IN MMU IMAGE 

3? 



'I* *1* *1* *1* *1* 

r,S 



REGISTER USE: 

PARAMETERS: 




- R0: DBR # 




=" R1 : SEGMENT 

3? 



R2: segment ADDRESS 

3? 



- R3: SEGMENT ATTRIBUTES 




R4: SEGMENT LIMITS 




’i' LOCAL VARIABLES: 

3? 



^ R10: MMU EASE ADDRESS 

3iS 



R13: OFFSET VARIABLE 

3(4 



ap3jc3?5;«a^sjs:ss>j:3jcjjc3?3;c::p3p;:p:p^a;c;;:>jcs;c3;C3jc3}saiS3;cy,c^3^;;«3?^« f 



ENTPT 


0060 

210A 

LD R10, #MMU IMAGE ! MMU BASE ADDRESS ! 

0062 

0000' 



0064 

S10A 

ADD R10, R0 


0066 

210D 

LD R13, #SIZSOF SEG_DSSC_HEG 


006B 

0004 



006A 

991C 

MULT RR12, R1 ! COMPUTE SEG 

DESC OFFSET 

006C 

eiDA 

ADD E10, R13 !ADD OFFSET TO 
! INSERT DESCRIPTOR DATA ! 

BASE ADDRESS 

006E 

2rA2 

LD OR10, R2 


0070 

A9A1 

INC R10, #2 


0072 

0DA8 

CLR GR10 


0074 

2EAC 

LDB GR10, RL4 


0076 

A9A0 

INC R10, #1 


0078 

20AC 

LDB RL4, GR10 


007A 

0A0E 

CP3 RL3, #'i;(2)00001000 ! EXECUTE ! 

007C 

0808 



007E 

5E0S 

IF EO TEEN 


0080 

00eA' 



0082 

060C 

ANDB RL4, #%(2)11110111 

! EXECUTE ^ 

0084 

F7F7 



0086 

5E08 

ELSE 


0088 

00eE' 



008A 

060C 

ANDB RL4, #%(2)11111110 

! READ MASK 

008 C 

FEFE 

FI 


008E 

84BC 

ORB RL4, RL3 


0090 

2SAC 

LDB GR10, RL4 


0092 

9E08 

RET 


0094 


END nPBATE_MMD_lMAGE 



^^^b 





i 




0094 


0094 7C01 

0096 7604 
0098 0000' 
009A 5F00 
009C 0’^82' 


00AE 001E' 
0030 FFFF 
0032 5E0E 
0034 e0EA' 


0036 0303 
0038 FFFF 
00BA 5E0E 
0030 00CA' 
003E 2100 
0000 0003 
0002 7601 


WAIT PROCEDURE 

- INTPA_KERNEL STNC/COf^ PRIMATIVE - 
’P INVOKED 3Y KERNEL PROCESSES 

;(C 9ic 9): ^ ^ ;;c ^ ::c qc V V ^ ^ >r 3r V’It ^ ^ ^ ^ ^ 

PARAMETERS 

’i' R8(R9): MSO POINTER (INPUTS 

’i' R1 : S£NDING_VP (RETURN) 

- GLOBAL VARIABLES 

R14: L'BR (PARAM TO GETWORK ^ 

’i' LOCAL VARIABLES 

- R2: CURRENT_VP (RUNNING) 

R3: NEXT_READY_VP 

’i' R4: LOCK ADDRESS 

^ R13: LOGICAL CPU NUMBER - 

ENTRY 

! MASK INTERRUPTS ! 

DI VI 
! LOCK VPT ! 

LDA R4, VPT.LOCK 






SP 


CALL 


SPIN LOCK ! (R4:''VPT.L0CK) ! 


! NOTE: RETURNS WHEN VPT IS LOCKED BY THIS VP ’ 
! GST CPU NUMBER ! 


HI :CPU ff 
R2:# VP'S! 


009E 

00A0 

5F00 

02 ce' 

CALL 

GET 

00A2 

AllD 

LD 

R13 

00A4 

00A6 

61D2 

0002' 

LD 

R2, 

00A8 

00AA 

6123 
001C ' 

LD 

R3, 

00AC 

4D21 

CP 

VPT 


VPT.VP.MSG_LIST(R2), #NII 

I? EC ! CURRENT VP'S ^-SG LIST IS EMPT^ ! THEN 

! REMOVE CURRENT_VP FROM R£AEY_LIST ! 
j V V V V D R 3 U G '■* '•* ! 

CP R3, #NIL 

IF EC THEN 

LD fi0, #R_L_E ! READY LIST EMPTY ! 
LDA ai, $ 
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0004 

00C2' 



00C6 

5F00 


CALL MONITOR 

00C8 

A900 


FI 

! ^ END DERUG v i 

00CA 

6FD3 

LD 

VPT.R£ADY_LIST(R13) , R3 

00CC 

0006' 



00CE 

4D25 

LD 

VPT. VP .NEXT_READY_VP (R2'i , <^NIL 

00D0 

001C' 



00D2 

FFFF 

! PUT 

IT IN WAITING STATE ! 

00D4 

4D25 

LD VPT 

.VP.STATS(R2) , ^^WAITING 

e0D6 

0014' 



00D8 

0002 

! SET 

DPR ! 

00DA 

612E 

LD 

R14, VPT.VP.rfR(R2) 

00DC 

0010' 





! SCHEDULE FIRST ELGIBLi READY VP ! 

00DE 

93F8 

PUSH 

GRlb.RB 



! SAVE 

LOGICAL CPU # ! 

00E0 

93FD 

PUSH 

ORlb, R13 

00E2 

5F00 


CALL GETWORK !R13:C?U a 

00E4 

0000' 


R14 :DER ! 



! RESTORE CPU tf ! 

00E6 

97FD 

POP 

R13, 0R15 

00E8 

97F8 

POP 

R8,0R15 


FI 

! GET FIRST !^SG ON CURRENT VP'S ^'SG LIST ! 


00EA 5F00 CALL GET FIRST_.'^SG ! COPIES MSG IN MSG ARRA 
e0EC 00C2' 

! R13: LOGICAL CPU 
!RETURNS RlrSENLER 

! UNLOCK VPT ! 

00EE 4D08 CLR VPT.LOCK 
00F0 0000' 

! UNMASK VECTORED INTERRUPTS ! 

00F2 7C05 El VI 

! RETURN: Rl:SENDER VP ! 

00F4 9E08 RET 

00F6 END WAIT 


























00F6 SIGNAL PROCEDUEE 

INTRA KERNEL SYNC /COM PRIMATIVE - 
^ INVOKED PY KERNEL PROCESSES - 


- REGISTER USE; 

PARAMETERS: 

R8(R9); MSG POINTER (INPUT) 

- R1 : SIGNALED VP_ID (INPUT) - 

^ GLOBAL VARIABLES 

- R13: CPU # (PARAM TO GETWORK ) 

- R14: DER (PARAM TO GETWORK) 

LOCAL VARIABLES: 

’i* Rl; signaled VP - 

R2: CURRENT_VP - 

’i' R4; VPT.LOCK ADDRESS 


ENTR^ 

! SAVE VP ID ! 


00E6 

93F1 

PUSH 

PR15, Rl 



! mask 

INTERRUPTS ! 

00F8 

7C01 

Dl 

VI 



! LOCK 

VPT ! 

00FA 

7604 

LDA 

R4, VPT.LOCK 

00FC 

0000' 



00FE 

5F00 

CALL 

SPIN_LOCK ! (R4 ;''VPT.LOCK) ! 

0100 

0282' 





!NOTE: 

RETURNS WHEN VPT IS LOCKED BY THIS 



! GET 

LOGICAL CPU ff ! 

0102 

5F00 

CALL 

GET_CPU_NO !RETURNS: 

0104 

02C8' 






RlrCPU ^ 




H2;tt VP'S! 

0106 

AllD 

LD 

R13, Rl 



! RESTORE VP ID ! 

0108 

97F1 

POP 

Rl» ORIS 



! PLACE MSG IN SIGNALED VP'S MSG LIST ! 

010A 

5F00 

CALL ENTER MSG LIST !(R8;MSG POINTER 

010C 

005C ' 


RltSIGNALED VP 




E13: LOGICAL CPU ff) 

010E 

4D11 

CP 

VPT.VP.STATE(R1 ) , ^rWAlTlNG 

0110 

0014 ' 



0112 

0002 



0114 

5E0E 

IF SO 

! SIGNALED_VP IS WAITING ! THEN 

0116 

0148' 





! WAKE IT UP AND MAKE IT READY ! 

0118 

A112 

LD 

R2, Rl 

011A 

76D3 

LDA 

R3, VPT.READY LiST{Rl3) 
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011C 

0006 ' 




011B 

7604 

LDA 

R4, 

VPT.VF.NEXT_R£ADY 

0120 

eeic' 




0122 

7605 

LDA 

R5. 

VPT.VP.PRI 

0124 

0012' 




0126 

7606 

LDA 

R6, 

VPT.VP.STATE 

0128 

0014' 




012A 

2107 

LD 

R7, 

#RSADT 

012C 

0001 

! SAVE 

LOGI 

CAL CPU ff ! 

012E 

93FD 

PUSH 

0R15, R13 

0130 

bF00 

CALL 

LIST INSERT !R2: OifJ 

0132 

0000=«' 





H3: 

LIST PTR 

ADD?, 

R4: 

NEXT OEJ 

PTR 

R5 : 

peiorityI 

PTR 

R6: 

STATE_rTR 


R7: 

STATE ! 



! RESTORE LOGICAL CPU n ! 


0134 

97FD 

POP 

R13, GR15 



! PUT 

CURRENT VP IN HEADT STATE ! 

0136 

61D2 

LD 

R2, 7PT.RUNNING_IIST(R13^ 

0138 

0002' 



013A 

4D25 

LD 

VPT. VP. STATE ( R2 ) , <?READY 

013C 

0014' 



013E 

0001 

» PT 

• *j i. 

D3R ! 

0140 

612E 

LD 

R14, VPT.VP.DPR(R2^ 

0142 

0010' 





! SCHEDULE FIRST ELGIRLE READY vp ! 

0144 

5F00 

CALL 

GETWORK !R13;I0GICAL CPU 

0146 

0000' 

FI 

?14;DBR ! 



! UNLOCK VPT ! 

0148 

4D08 

CLR VPT.LOCK 

014A 

0000' 





! UNMASK VECTORED INTERRUPTS ! 

014C 

7C05 

El 

VI 


014E 9E08 RET 
0150 END signal 
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SET preempt PROCEEURE 

SETS PREEMPT INTERRUPT ON- 

- TARGET_?P. CAlIED BT TC_ 

ADVANCE. 

s?j;; jp JS sp V V V V sp >? 5? 5? 5? sp ap ir V »P >;« jp =P a? s;« S? 

- REGISTER USE: 

PARAMETERS : - 

^ PI:TARGET_VP_ID (INPUT) - 

- LOCAL VARIABLES - 

^ Rl: VP_INDEX =5* 

vappcpapapapap I 

ENTPT 

!*NOTE: DESIGNED AS SAEE SEC'JENCE 
NOT BE LOCKED. ! 


SC VFT NEED 


0150 

0152 


6112 

0210 ' 


! CONVERT 
ID 


V?_ID TO VP INDEX ! 
R2. EXT VP LIST(R1^ 


0154 4D25 
0156 0018' 
0158 FEFF 


! TURN ON TGT_VP PREEMPT FLAG ! 

ID VPT.VP.PREEMPT(P.2) . #0N 


! IF TARGET VP NOT LCCAL 

( NOT BOUND TO THIS CPU ) 

(IE, IF <<cpu_seg»cpu_id<>vpt.vp.pkys_cpu(ri) 

TEEN SEND HARDWARE PREEMPT INTERRUPT TO 
VPT.VP.CPU(Rl) . ! 


01 5A 9E0e 
015C 


RET 

END SE' 


PREEMPT 
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015C 


IDLE PROCEDURE 

f 'I* «y« ifi 2 | 0 |« «|« * 1 % «|% * 1 % «|» * 4 * 

’i' LOADS IDLE DBR ON 
^ CURRENT VP. CALLED B'i - 
'•* TC_GETWO^fC. 

3^ sjc ^ 3;c 3^ :;c ^ 3;c 9;c ^ 

- REGISTER USE - 



GLOBAL variable 

3,C 

3? 

R13: LOG CPU # 

V 


PI4: DBR 

V 


LOCAL VARIABLES: 

i.C 


R2: CURRENT VP 


3«C 

R3; TEMP VAR 

3? 


R4: 7PT.L0CK ADDR 



R5: TEMP 

nS 


015C 5F045 


^>iS5i£S?J!S!?S?>i«5i«»itn:’?5PS!C>?S?S?:iSSiSSiCS;SS?V5r5;e J 

ENTRY 

! GET LOGICAL CPU # ! 

CALL GET CPU NO !RETURNS 


! LOAD IDLE DBR ON CURRENT VP ! 


0174 

6103 

LD 

R3, PRDS.IDLE_VP 

0176 

0A10' 



0178 

6135 

LD 

R5, VPT.VP.DER(R3) 

017A 

0010' 



017C 

6F25 

LD 

VPT.VP.DBR(R2), R5 

017E 

0010' 





! TURN ON current VP'S IDLE FLAG ! 

0180 

4D25 

ID 

VPT .VP. IDLS_FLAG(R2) , ^^ON 

0182 

0016' 



0184 

FFFF 





! SET 

VP TO READY STATE ! 

0186 

4D25 

LD 

VPT.VP.STATE(R2K #RSAEY 

0188 

0014' 



016A 

0001 





! SCHEDULE FIRST ELIGIBLE READY VP 

018C 

5F00 

CALL 

GETWORK !R13:L0GICAL CPU « 

018E 

0000' 






R14:DRR ! 



! UNLOCK VPT ! 

0190 

4D08 

CLR 

VPT.LOCK 

0192 

0000' 





! UNMASK VECTORED INTERRUPTS ! 

0194 

7C05 

SI 

VI 

0196 

9E08 

RET 


0198 


END IDLE 
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^198 


0198 93n 

019A 7C01 

019C 7804 
019E 0000' 
01A0 5F00 
01A2 0282' 


01A4 5F00 
01A6 02C8' 


01A8 AllD 

01AA 61D2 
01AC 0002' 

01AE 4D21 
01JJ0 001E' 
01B2 FFFF 
01B4 5S08 
01B6 01C4' 
0138 2100 
01BA 0005 
01BC 7601 
01BE 01EC ' 
01C0 5F00 
01C2 A900 


SWAP 7BER PROCEDURE 


LOADS NEW DBR ON 
CURRENT VP. CALLED 3 - 

- TC_GETWORK. 

’f REGISTER USE 

- PARAf^ETERS - 

^ Rl: NEW_DBR (INPUTS 

- GLOBAL variables 

- R13: LOGICAL CPU # - 

R14: DBR - 

^ LOCAL VARIABLES - 

- R2; CURRENT_VP - 

R4: VPT.LOCK ADDR ^ 

j^jpvspsr Ji*3r5FV5P>S»iS5?=i'S?>!!J)!JJtJ?:SS>i«sp5!!5p5?= j 

ENTRY 

! SAVE NEW DBR ! 

PUSH PR15, Rl 

! MASK INTERRUPTS ! 

DI VI 
! LOCK VPT ! 

LDA R4, VPT.LOCK 


CALL SPIN lock ! (R4 :''VPT .LOCK) ! 


! NOTE: RETURNS WHEN VPT IS LOCKED BY THIS VP. 
! GET CPU # ! 

CALL GST_CPU_NO. ’RETURNS: 

Rl: CPU if 
R2:»^ VP'S! 

L r R13 R1 

! GET current’VP ! 

LD R2, VPT.RUNNING_LIST(R13) 

I V debug V s;! v j 

CP VPT. VP. MSG LIST(R2), ^^NIL 


IF NE ! MSG waiting ! THEN 
LE R0, #S_N_A ! SWAP NOT ALLOWED 
LDA Rl, $ !PC! 

CALL MONITOR 
FI 

! - END DEBUG ! 

! SET DBR ! 
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VPT.VP .DEH(HH) 


01C4 

612E 

LD 

R14, 

01C6 

0010 ' 

! REST' 

ORE NEW 

01C8 

97?0 

POP 

R0, 

01CA 

5F00 

CALI 

GET_ 

01CC 

000A' 

! LOAD 

NEW DBR 

01CE 

5F21 

LD 

VPT. 

01D0 

0010' 

! TURN 

OFF IDL 

01D2 

4D25 

IE 

VPT. 

01D4 

0016 ' 



01D6 

0000 




DBR ! 

(?R15 

DER_ADDR ! fR4?: lER ff) 

RETURNS 
(Rl: EER AEER^ 

ON CURRENT V? ! 

VP.DER(Rki^. Rl 


E FLAG ! 

VP. IDLE FIAG(R2), ^^CFF 


! SET VP TO READY STATE ! 

01D6 4D25 LD VPT .VP .STATE(R2 ) , ^REAEl 

01DA 0014' 

01DC 0001 


! SCHEDULE FIRST ELGIELE READK VP ! 
eiDE bFe0 CALL GETWORK !R13:I0GICAL CPU » 
01E0 0000' 

R14:DER ! 




! UNLOCK VPT ’ 

01E2 

4D08 

CLR VPT.LOCK 

01E4 

0000' 

! UNMASK VECTORED INTERRUPTS 

01E6 

7C05 

£I VI 

01E8 

9E0e 

PET 

01EA 


END SWAP_VDER 


» 
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eiEA 


PEYS_PREEf"PT_HANI}LER PROCEEURE 

- hardware PRSEr^P? INTERRUPT - 

handler, also tests pgr 
V virtual preempt interrupt ^ 

- flag and invokes interrupt 

- HANDLER IF FLAG IS SET. 

- INVOKED UPON EVERY EXIT FROi^ ^ 

- KERNEL. KERNEL FC',V i^.ASKS - 

NVI INTERRUPTS TO PREVENT 
SIMULTANEOUS PREEMPT INTERR. 
HANDLING. 

:yC3iC3)C3;c3;s3(cV^^^^^ 


REGISTER USE - 

- LOCAL VARIAPLES 

Rl: PREEMPT_INT_FLAG 

- R2: CUPRENT_V? 

- GLOBAL VARIABLES - 

^ R13:L0GICAL CPU ^ ^ 

^ P14:DBR 


ENTRY 


1 5 ;! =;< preempt handler ^ ^ ! 




! SAVE 

ALL REGISTERS ! 

eiEA 

030F 

SUB 

R15, #32 

01 EC 

0020 



01 EE 

1CF9 

LDM 

0R16, Rl. #16 


fe'lFO aiHF 


7V6'7 
fe?lF4 93F6 

01F6 5Fe0 
01FB 0HC8' 


01FA AllD 

01FC 7C01 

01FE 7604 
0200 0000 ' 
0202 5F00 
0204 0282' 


0206 61D2 


! SAVE NORMAL STACK POINTER (NS?) 
LDCTL R6, NSP 

PUSH OR15, R6 

! GET CPU f* ! 

CALL GET_CPU_NO 'RETURNS: 

Rl: CPU ^ 

R2:ti VP 'S ! 

LD P.13, Rl 

MASK INTERRUPTS ! 

DI VI 
! LOCK VPT ! 

LDA R4, VPT.LOCK 

CALL S?IN_LOCK 

!RETURNS WHEN VPT IS LOCKED! 

! SET DBR ! 

LD R2, VPT.RUNNING LIST(R13) 
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C208 

0002' 




0^0 A 

612S 

LD ' 

R14, VPT.VP.DER(R2) 


020C 

0010' 






! PUT 

CURRENT PROCESS IN READY 

ST* TE 

020E 

4D25 

LD 

VPT. VP.STATE(R2K #HE 

ACY 

0210 

0014' 




0212 

0001 




0214 

bF00 

CALL 

GETiCRK !Rib:LOG CPU 

tt 

0216 

0000' 







R14:DER ! 




PREEMPT 

RET ^ 




! UNLOCK VPT ! 


0218 

4D0e 

CLR 

VP'^.LOCK 


021A 

0000' 






! unmask VECTORED INTERRUPTS ! 


021C 

7C05 

El 

VI 



KERNEL EXIT: 

I UNMASK VIRTUAL PREEMPTS ! 

! NOTE: SAFE SEQUENCE AND EOES NOT PEQUI?. 
7PT TO BE LOCKED. ! 




! GET 

CURRENT VP ! 

021E 

610D 

LD 

R13, PRDS.LOG_CPU_ID 

0220 

0A0C ' 



0222 

61D2 

LD R2 

, 7PT.RUNNING_LISTfRl3) 

0224 

0002' 





j ppeemPT interrupt FLAG J 

0226 

4D21 

CP 

VPT.VP.PREEMPT(R2 1 . ^^ON 

0228 

0018 ' 



022 A 

FFFF 



022C 

5E0E 

IF SO 

! PREEMPT FLAG IS ON ! THEN 

022E 

0240' 

j 

RESET PREEMPT FLAG ! 

0230 

4D25 

LD 

VPT.VP.PREEMPT(H2^ , »OFF 

0232 

0018 ' 



0234 

0000 

! 

SIMULATE VIRTUAL PREEMPT INTERRUPT 

0236 

2101 

LD 

Rl, 

0238 

0000 



023A 

6112 

LD 

R2, VPT.VIRT_INT_VEC(Rl) 

023C 

000C ' 



023E 

1S28 

JP 

0^2 


!NOTE: THIS JUMP TO TRA?FIC_C0NTR0L 
IS USED ONLY IN THE CASE OF A PREEMPT INTEERU 
AND SIMULATES A HARDWARE INTERRUPT. -- ! 


! END VIRTUAL PREEMPT HANDLER ! 

FI 

















! NOTE: SINCE A HDWE INTERRUPT DOSS NOT EXIT 
THEUUOF THE OATS, THOSE EUNCTIONS PROVIDED 
3Y A GATE EXIT TO HANDLE PREEMPTS MUST EE 
PROVIDED HERE ALSO. ! 

! RESTORE NSP ! 


0240 

9'7Fb 

POP R6, 

fiRl5 

0242 

7D6F 

LDCTL 

NSP, H6 



! RESTORE ALL REGSTERS 

0244 

ICFl 

LDM 

Rl, 0R16, "16 

0246 

010F 



0248 

010F 

ADD 

R15, #*22 


(/24:A eeno 

! EXECUTE HARDWARE INTERRUPT RETURN ! 
024C 7B00 IRET 

024E END PHYS PREEMPT HANDLER 
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i?24£ 


p_NN_lNG_yP.PHOCijG'JRE 

CALLED £Y TRAFFIC CONTROL. =" 
==» RETURNS VP ID, RESULT IS VALID’'-' 

- ONLY WrilLE'APT IS LOCKED. 

:SCV ^ ^ 7 ^ ^ V ^ ^ ^ ^ ^ ^ ^ ^^ ^ ^ ^ ^ ^ ^ ^ ^ 

’i' REGISTER USE 

’•' PARAMETERS ’■' 

Rl: EXT_VP_ID (RETURNED) - 
’!' R3: LOG CPU > (RETURNED) ’'■' 

- LOCAL VARIABLES 

’i' R2: VP INDEX 

ENTRY 

I MASK INTERRUPTS ! 


024E 

7C01 

DI VI 




! LOCK VPT ! 

e25e 

7604 

LDA 

R4, VPT.LOCK 

0252 

0000' 



0254 

5F00 

CALL 

SPIN_LOCK ! (R4;''VPT.L0CK) ! 

0256 

0282' 





! NOTE; RETURNS 'J/HEN VPT IS LOCKED RY THIS 
! GET LOGICAL CPU V ! 

0258 

5F00 

CALL 

GET_CPU_NO IHETURNS; 

025A 

02C8 ' 


Rl; CPU tt 

R2:# VP'S! 

025C 

A113 

LD 

R3, Rl 

025E 

6132 

LD 

R2, VPT.RUNNING_LIST(R3) 

0260 

0002' 





! CONVERT 

V? INDEX TO VP ID ! 

0262 

6121 

LD 

Rl, 7PT.VP.EXT_ID(R2) 

0264 

0020' 


DERUG 5? »:« >? ! 

0266 

0E01 


CP Rl, */NIL 

0268 

FFFF 



026A 

5E0E 


IF EQ ! KERNEL PROC ! THEN 

026C 

027A ' 



026E 

2100 


LD R0, ^#V_I_E ! VP INDEX ERROR 

0270 

0006 



0272 

7601 


LDA Rl, S 

0274 

0272 ' 



0276 

5F00 


CALL MONITOR 

0278 

A900 


FI 

! ’i' END DEBUG ! 



! UNLOCK 

VPT ! 

027A 

4D08 

CLR 

VPT.LOCK 

027C 

0000 ' 

! UNMASK 

VECTORED INTERRUPTS ! 

027E 

7C05 

El VI 


0280 

9E08 

RET 


0282 


END RUNNING 

VP 


22G 






4 | 





0882 0D41 
0284 0000 
0286 5E06 
0288 0296' 
028A 2100 
028C 0000 
026S 7601 
0290 026E' 
0292 5F00 
0294 A900 


0296 0D46 
0298 E5fE 


029A 9E0e 
029C 


SPIN LOCK FP.OCSDTJRE 

USES SPIN_LCCK MECh. 

- LOCKS UNLOCKED DATA 
>;« STHUCTUHE (POINTED TO 
BY INPUT PARAMETER). - 


’^‘REGISTER USE 
^ PARAMETERS - 

- P4: LOCK ADDR (INPUT)- 

Sii3sc:^^3)cisc3jcifi3ic3!cs!c3ic3;^3jcs;:3ic:;c3ic3jc}}:3i:si!ii!es^s;: J 

ENTRY 

t NOTE: SINCE ON L"^ ONE PROCESSOR CURRENTLY 
IN SYSTEM, LOCK NOT NECESSARY. ! 
j :5t debug ^ ^ I 
CP GR4, itOFF 

IF NE ! NOT UNLOCKED ! THEN 
LD R0, PU_L ! UNAUTHORIZED LOCK ! 

LDA Rl, S 
CALL MONITOR 
FI 

! END DEBUG ! 

TEST_LOCK: 

! DO WHILE STRUCTURE LOCKED ! 

TSET GR4 

JP TEST_LOCK 

! -- NOTE SEE PLZ/ASM MANUAL 
FOR RESTRICTIONS ON 
USE OF TSET. -- ! 

RET 

END SPIN LOCK 
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^29C 


ITC_GST_SEG_PTR PROCEDURE 

GETS EASE ADDRESS OF SEGr^ENT - 
’*' INDICATED. - 

5J% 5i< $,» 3|« 3|C S|% )|C 35 c 3|« jiJC 5^S ^ JJ% #|S 55€ 3|C 3{C JjS JJ% SJS Sji 5JC 3)C 3|C 


REGISTER USE: - 

fl0;SEG BASE ADDRESS (RET ^ ^ 

RltSEG NP (INPUT) 

- R2:RUNNING_VP (LOCAi) - 

R3:D£R_VALUS (LOCAL) 

^ R4:7PT.LOCK - 

- Rl3:LOGI CAL CPU n 


e29C 93F1 

029E 7C01 

02A0 7604 
02A2 0000' 
e2A4 5F00 
02A6 0282' 

e2AB 5F00 
02AA 02C8' 


02AC AllD 

02AE 97P1 
02B0 61D2 
02B2 0002' 
02B4 6123 
02B6 0010' 

02Be 4D08 
02BA 0000' 

02BC 7C0b 
02BE 1900 
02C0 0004 
02C2 7130 
02C4 0100 

02C6 9E08 
02C8 


ENTRY 
! SAVE 

SEGMENT ! 

PUSH 

0R15, R1 

! MASK 

INTERRUPTS ! 

DI 

VI 

! LOCK 

VPT ! 

LDA 

R4,VPT.LOCK 

CALL 

SPIN_LOCK !R4:''VPT. LOCK! 

! GET 

CPU # ! 

CALL 

GFT_CPU_NO !RETURNS: 

LD 

R1 : CPU # 
R2:# VP 'S ! 

R13, R1 

! RESTORE SEGMENT n ! 

POP 

Rl. 0R15 

LD 

R2,VPT.RUNNING_LIST(R13) 

LD 

R3.VPT.VP.DBR(R2) 

! UNLOCK VPT ! 

CLR 

VPT.LOCK 

! unmask VECTORED INTERRUPTS ! 

El 

VI 

MULT 

RR0,#4 

LD 

R0.R3(R1) 

RET 



END ITC GET SEG PTR 


222 






















02CS GST CPU NO PROCEDURE 

- SIND CURRENT CFU_NO - 

- CALLEI) BY UIST MMGR 
=p AND MM 

^ jp V Jie sp J? ’it s? s? V 5;: 5?»? >? W SK V JJt v V >? sp 

- RETURNS - 

- Rl: CPU NO ==* 

- R 2 : # of VP'S - 


02C8 

6101 

ENTRY 

ID 

Rl, PRDS .IOG_CPU_ID 

02CA 

02CC 

0A0C ' 
6102 

LD 

R2, PRDS.VP_NR 

02CE 

02D0 

0A0S ' 
9E08 

RET 


02D2 

END 

GET_CPU. 

_N0 


02D2 

K_LOCK 

PROCEDURE 


f ^ nS ip3^5 V^ ^ V s^ss,? 

9,1 'p3p ip ip V i,S iiS 


'i' STUB FOR WAIT 

LOCK ’i' 


JiS s? 5? vpe sp Jr sp tp sp W sp jp’P W 5? 5? spsp sp 5p >? W 


- R4:''LOCK (INPUT) - 

3;s^;^;p9;c:;t^;p^9;:’>t’PP<’Ptp’P’P’PPt’P’P’P’P’P’P f 



ENTRY 

02D2 

5F00 CALL 

0 2D4 

0282' 

02D6 

9E08 RET 

02D8 

END K_LOCK 

02D8 

K UNLOCK 


SPIN LOCK 


PROCEDURE 

I sjcap’p^’iCSiiV’P’P’P’P’P’PV’P’P’P’P’P’P’P’P’PPt’P 

STUB FOR wait UNLOCK - 

^ ;;c 9;^ ^ ^ 3;cs;c ^ ^ 3;c V ^ ^’ic 

V R4:''LOCK (INPUT) 

»r* #1* ^ «!<• #1^ *»* n* *»* 'i* 'TT "T* »i* 'I* *i» ■ 


ENTRY 

e2D8 0D48 CLR CoR4 

02DA 9E08 RET 

02DC END K UNLOCK 


END INNER TRAFFIC CONTROL 
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